SQL Server na maszynie wirtualnej

SQL Server na maszynie wirtualnej licencjonuje się według rdzeni przypisanych do tej maszyny lub całego hosta.

Jak działa SQL Server uruchomiony w maszynie wirtualnej

SQL Server na maszynie wirtualnej działa jako usługa systemu operacyjnego zainstalowanego wewnątrz środowiska gościa. Maszyna wirtualna otrzymuje przydzieloną liczbę wirtualnych procesorów, pamięć operacyjną, wirtualne dyski oraz interfejs sieciowy. SQL Server korzysta z tych zasobów tak, jak korzystałby z zasobów komputera fizycznego, ale ich dostępność zależy również od konfiguracji hypervisora i obciążenia fizycznego hosta.

Wirtualizacja nie zmienia podstawowych mechanizmów silnika SQL Server. Nadal działają instancja, bazy danych, pliki danych MDF i NDF, pliki dziennika LDF, tempdb, mechanizmy blokad oraz punkty kontrolne. Zmienia się natomiast warstwa sprzętowa, na której system widzi procesory i urządzenia magazynujące. Ma to znaczenie dla wydajności, monitorowania oraz sposobu przypisania licencji.

Rdzenie wirtualne a zasady licencjonowania

W modelu licencjonowania SQL Server według rdzeni podstawą jest liczba wirtualnych rdzeni przydzielonych konkretnej maszynie wirtualnej. Licencjonowany zakres nie wynika wyłącznie z chwilowego użycia procesora, lecz z konfiguracji maszyny i obowiązujących zasad dla wybranej edycji SQL Server. Jeżeli do maszyny zostanie przypisanych więcej wirtualnych procesorów, może to zwiększyć liczbę wymaganych licencji, nawet gdy rzeczywiste obciążenie pozostaje niewielkie.

Drugim podejściem jest licencjonowanie całego fizycznego hosta. W takim wariancie licencje obejmują fizyczne rdzenie serwera zgodnie z regułami wybranego modelu, a uruchamiane na nim maszyny wirtualne są rozpatrywane w ramach uprawnień wynikających z licencji. Szczegółowe warunki zależą między innymi od edycji SQL Server, rodzaju posiadanej licencji, aktywnej umowy Software Assurance albo subskrypcji oraz praw do uruchamiania instancji. Sama obecność hypervisora nie zastępuje licencji i nie powoduje automatycznego zwolnienia z obowiązku ich posiadania.

Przy ocenie konfiguracji trzeba rozdzielić licencjonowanie SQL Server od licencjonowania systemu operacyjnego oraz oprogramowania dodatkowego. Windows Server, hypervisor, narzędzia do wykonywania kopii zapasowych i inne składniki środowiska mogą podlegać odrębnym zasadom. Dokumentowanie liczby rdzeni fizycznych, rdzeni wirtualnych, hostów oraz lokalizacji maszyn pomaga uniknąć błędnego przypisania licencji po zmianie konfiguracji.

Wpływ warstwy wirtualnej na wydajność bazy

Najczęstsze problemy techniczne wynikają z niedopasowania zasobów maszyny wirtualnej do obciążenia SQL Server. Zbyt mała liczba wirtualnych procesorów może wydłużać wykonywanie zapytań, ale nadmierne przydzielenie vCPU również nie gwarantuje poprawy. Hypervisor musi zaplanować pracę wirtualnych procesorów na fizycznych rdzeniach. Przy silnym współdzieleniu zasobów może pojawić się opóźnienie oczekiwania na procesor, mimo że system gościa nie raportuje pełnego wykorzystania CPU.

Duże znaczenie ma magazyn danych. Pliki baz danych i dzienników transakcji powinny znajdować się na zasobach o przewidywalnych czasach odpowiedzi, ponieważ opóźnienia operacji wejścia i wyjścia bezpośrednio wpływają na zapytania, zatwierdzanie transakcji oraz działanie tempdb. Warstwa wirtualnego dysku, kontroler, pamięć podręczna hosta i współdzielenie macierzy mogą zmieniać wyniki pomiarów. Sama wysoka przepustowość sekwencyjna nie wystarcza do oceny środowiska SQL Server; trzeba analizować również opóźnienia i operacje losowe.

W diagnostyce warto porównywać metryki z systemu gościa z danymi hypervisora. Należy sprawdzić zużycie CPU, oczekiwanie procesora, dostępność pamięci, presję pamięci, opóźnienia dysków oraz przepustowość interfejsu sieciowego. Istotne są także ustawienia planu zasilania, dynamiczne zmiany pamięci, limity zasobów i mechanizmy nadmiernej alokacji. Objaw w postaci wolnego zapytania nie musi oznaczać błędu samego zapytania, jeżeli przyczyną jest opóźnienie infrastruktury wirtualnej.

Kontrola konfiguracji i bezpieczne utrzymanie instancji

Przegląd SQL Server w maszynie wirtualnej powinien rozpocząć się od ustalenia edycji i wersji silnika, modelu licencjonowania, liczby przydzielonych vCPU oraz parametrów pamięci. Następnie należy zweryfikować lokalizację plików baz danych, dzienników i tempdb, dostępne miejsce, opóźnienia magazynu oraz harmonogram kopii zapasowych. Kopia zapasowa nie jest równoważna testowi odtworzenia, dlatego okresowo trzeba sprawdzać, czy backup można poprawnie odczytać i przywrócić.

Zmiana liczby procesorów, pamięci, magazynu lub hosta może wpłynąć jednocześnie na wydajność, dostępność i zgodność licencyjną. Migracja maszyny wirtualnej pomiędzy hostami wymaga uwzględnienia praw do przenoszenia instancji oraz warunków umowy licencyjnej. Przy problemach z działaniem bazy nie należy zaczynać od przypadkowego zwiększania zasobów. Najpierw trzeba zebrać dane z SQL Server, systemu gościa i hypervisora, a potem powiązać czas wystąpienia problemu z obciążeniem procesora, pamięci, dysków lub sieci.

Serwisowa ocena takiego środowiska obejmuje analizę konfiguracji komputera, systemu oraz objawów zgłaszanych przez użytkownika. W przypadku nieprawidłowego działania potrzebne jest rozróżnienie problemu sprzętowego, systemowego, wirtualizacyjnego i związanego z samym silnikiem bazy danych. Takie rozdzielenie ułatwia wskazanie rzeczywistej przyczyny bez przypisywania awarii wyłącznie SQL Server albo wyłącznie maszynie wirtualnej.