Licencjonowanie Microsoft SQL Server - najczęstsze błędy wykrywane podczas audytów i jak ich uniknąć

Dlaczego licencjonowanie Microsoft SQL Server jest tak skomplikowane?

Licencjonowanie Microsoft SQL Server należy do najbardziej złożonych obszarów zarządzania oprogramowaniem w środowiskach serwerowych. Windows Server, SQL Server, licencje dostępowe CAL oraz Software Assurance tworzą system zależnych od siebie zasad, których nieprawidłowa interpretacja może prowadzić do poważnych konsekwencji finansowych.

W praktyce większość problemów nie wynika z celowego naruszania warunków licencyjnych. Znacznie częściej są efektem rozbudowy infrastruktury, migracji do środowisk wirtualnych, modernizacji sprzętu lub niewłaściwej interpretacji dokumentacji Microsoft Product Terms. Organizacje często zakładają, że zakup odpowiedniej liczby licencji gwarantuje zgodność. Tymczasem równie istotne jest to, w jaki sposób licencje zostały przypisane i wykorzystywane.

Audyt licencyjny Microsoft największe niezgodności najczęściej stwierdza w obszarach:

• SQL Server wirtualizacja - niewłaściwego licencjonowania środowisk wirtualnych,
• SQL Server Per Core - błędnego określania liczby wymaganych rdzeni,
• SQL Server Software Assurance - braku wymaganych uprawnień wynikających z Software Assurance,
• SQL Server Developer Edition - wykorzystywania edycji Developer w środowiskach produkcyjnych,
• SQL Server Server + CAL - stosowania nieaktualnych licencji CAL,
• komponenty SQL Server - braku odpowiedniego licencjonowania usług uruchamianych na odrębnych serwerach.

Większości tych problemów można uniknąć. Wystarczy odpowiednio zarządzać środowiskiem, dokumentować zmiany infrastruktury i regularnie weryfikować zgodność licencyjną z zasadami licencjonowania SQL Server.

Jakie modele licencyjne SQL Server oferuje Microsoft?

W przypadku licencjonowania SQL Server najważniejsze modele to SQL Server Per Core oraz SQL Server + CAL. W zależności od kanału zakupu i sposobu wdrożenia dostępne są również warianty subskrypcyjne oraz rozliczenia oparte na zużyciu.

SQL Server + CAL

Model SQL Server + CAL polega na zakupie licencji dla serwera oraz odpowiedniej liczby licencji dostępowych CAL dla użytkowników lub urządzeń.

Najlepiej sprawdza się w środowiskach, w których liczba użytkowników jest znana, dostęp do bazy danych jest ograniczony a z systemu korzysta stosunkowo niewielka grupa osób.

Przykładem mogą być wewnętrzne aplikacje biznesowe wykorzystywane wyłącznie przez pracowników firmy.

SQL Server Per Core

Model SQL Server Per Core polega na licencjonowaniu odpowiedniej liczby rdzeni - fizycznych lub wirtualnych, zależnie od wybranego sposobu licencjonowania i praw przysługujących organizacji.

Rozwiązanie to jest rekomendowane w przypadku: aplikacji internetowych, systemów ERP, systemów CRM, sklepów internetowych, środowisk o dużej liczbie użytkowników czy też aplikacji, w których nie da się określić liczby korzystających osób.

Model SQL Server Per Core nie wymaga zakupu licencji CAL, dlatego jest standardem w większości dużych przedsiębiorstw.

Licencjonowanie SQL Server - najważniejsze zasady

Licencjonowanie Microsoft SQL Server zależy m.in. od wybranej edycji, modelu licencyjnego oraz sposobu wdrożenia środowiska. Inne zasady mogą obowiązywać dla serwerów fizycznych, maszyn wirtualnych czy środowisk o wysokiej dostępności. Dlatego przed przypisaniem licencji warto przeanalizować zarówno konfigurację techniczną, jak i posiadane prawa licencyjne.

• SQL Server można licencjonować m.in. w modelu Per Core oraz Server + CAL.
• Przy licencjonowaniu VM w modelu Per Core obowiązuje minimum 4 core na VM.
• Licencjonowanie pojedynczej VM SQL od wersji Server 2022 wymaga odpowiedniej licencji subskrypcyjnej lub aktywnego Software Assurance.
• Software Assurance może zapewniać dodatkowe prawa, m.in. dotyczące mobilności licencji, HA/DR i wirtualizacji.
• W środowiskach VMware i Hyper-V należy analizować nie tylko konfigurację VM, ale także sposób przypisania licencji i możliwość migracji VM.

Najczęstsze błędy w licencjonowaniu SQL Server

Licencjonowanie Microsoft SQL Server od lat należy do obszarów, w których organizacje najczęściej popełniają błędy wykrywane podczas audytów. Wynika to z dużej liczby modeli licencyjnych, możliwości wdrożenia w środowiskach fizycznych i wirtualnych oraz dodatkowych uprawnień związanych z Software Assurance.

W przeciwieństwie do Windows Server, gdzie głównym wyzwaniem jest prawidłowe licencjonowanie fizycznych rdzeni oraz liczby maszyn wirtualnych, w przypadku SQL Server kluczowe znaczenie ma również sposób korzystania z infrastruktury oraz model licencjonowania wybrany przez organizację.

Najczęstszą przyczyną niezgodności licencyjnych SQL Server jest błędne założenie, że licencję zawsze można przypisać wyłącznie do maszyny wirtualnej. W praktyce zależy to od wielu czynników, w tym posiadanych praw licencyjnych.

Zbyt mała liczba licencjonowanych rdzeni

Jednym z najczęściej spotykanych błędów jest licencjonowanie wyłącznie zasobów aktualnie przydzielonych maszynie wirtualnej. Przykładem może być maszyna wirtualna, która posiada 2 vCPU i licencję SQL Server Standard 2022. Organizacja chce licencjonować tę VM w modelu Per Core i przypisała jej 2 vCPU. Na pierwszy rzut oka wydaje się to logiczne, jednak w praktyce środowisko może nie spełniać wymagań licencyjnych. Microsoft określa bowiem minimalny poziom licencjonowania dla maszyny wirtualnej.

Każda maszyna wirtualna z SQL Server licencjonowana w modelu Per Core wymaga pokrycia co najmniej czterema licencjami rdzeniowymi, nawet jeśli przypisano jej mniej niż cztery vCPU. To właśnie nieuwzględnienie minimalnych wymagań jest jedną z najczęściej wykrywanych niezgodności.

Nieprawidłowe licencjonowanie środowisk VMware i Hyper-V

Rozwój wirtualizacji sprawił, że większość nowych wdrożeń SQL Server działa obecnie na platformach takich jak: VMware, Microsoft Hyper-V, klastry wysokiej dostępności, środowiska hybrydowe. Choć rozwiązania te zapewniają dużą elastyczność, jednocześnie znacząco komplikują licencjonowanie SQL Server w środowisku wirtualnym. W wielu organizacjach nadal funkcjonuje błędne przekonanie, że licencję można przypisać wyłącznie do konkretnej maszyny wirtualnej, niezależnie od sposobu jej migracji pomiędzy hostami. W praktyce nie zawsze jest to możliwe.

Nowoczesne środowiska wykorzystują mechanizmy umożliwiające automatyczne przenoszenie maszyn pomiędzy serwerami fizycznymi. Najczęściej są to: VMware vMotion, Hyper-V Live Migration, klastry wysokiej dostępności, rozwiązania zapewniające automatyczne równoważenie obciążenia. Jeżeli maszyna z SQL Server może zostać uruchomiona na różnych hostach, sposób licencjonowania powinien uwzględniać taki scenariusz.

SQL Server CAL i multiplexing

W przypadku SQL Server licencjonowanego w modelu Server + CAL kluczowe znaczenie ma prawidłowe przypisanie licencji SQL Server CAL do każdego użytkownika lub urządzenia uzyskującego dostęp do serwera, zależnie od wybranego modelu licencjonowania. Jednym z najczęściej spotykanych błędów jest założenie, że liczba wymaganych licencji CAL zależy od liczby kont technicznych wykorzystywanych do komunikacji z bazą danych.

Problem ten pojawia się najczęściej w środowiskach, w których aplikacja biznesowa komunikuje się z SQL Server za pośrednictwem jednego konta serwisowego. Ponieważ z perspektywy bazy danych widoczne jest tylko jedno konto techniczne, organizacje często błędnie zakładają, że wystarczające będzie nabycie pojedynczej licencji SQL Server CAL. W praktyce takie podejście może prowadzić do naruszenia zasad licencjonowania związanych z tzw. multiplexingiem.

Wiele organizacji błędnie interpretuje takie rozwiązania jako sposób na zmniejszenie liczby wymaganych licencji SQL Server CAL. Tymczasem redukcja liczby połączeń, kont technicznych lub sesji widocznych na serwerze nie zmniejsza liczby użytkowników lub urządzeń faktycznie korzystających z danych przechowywanych w SQL Server. Każdy użytkownik lub każde urządzenie uzyskujące dostęp do danych, nawet pośrednio za pomocą aplikacji, nadal wymaga odpowiedniej licencji SQL Server CAL.

Nieprawidłowe wykorzystanie SQL Server Developer Edition

Edycja SQL Server Developer jest często wykorzystywana przez organizacje do celów programistycznych, testowych oraz szkoleniowych. Ze względu na pełną funkcjonalność odpowiadającą edycji Enterprise bywa traktowana jako atrakcyjna alternatywa dla licencji produkcyjnych. Jednocześnie jest to jeden z obszarów, w których podczas audytów regularnie wykrywane są nieprawidłowości.

Kluczowym ograniczeniem SQL Server Developer Edition jest zakaz wykorzystywania oprogramowania w środowisku produkcyjnym. W praktyce oznacza to, że licencja może być używana wyłącznie do projektowania, tworzenia, testowania i demonstracji aplikacji.

Szczególne znaczenie ma tutaj definicja środowiska produkcyjnego. Obejmuje ona nie tylko systemy obsługujące rzeczywiste obciążenia biznesowe lub uzyskujące dostęp do danych produkcyjnych, ale również fizyczne środowisko systemu operacyjnego hostujące co najmniej jedno wirtualne środowisko operacyjne działające z obciążeniem produkcyjnym lub uzyskujące dostęp do danych produkcyjnych. W praktyce oznacza to, że sam fakt uruchomienia SQL Server Developer Edition w fizycznym systemie operacyjnym hosta może być problematyczny, jeżeli na tym samym serwerze działają maszyny wirtualne wykorzystywane produkcyjnie.

Jest to jeden z najczęściej pomijanych aspektów licencjonowania tej edycji. Organizacje często przyjmują założenie, że SQL Server Developer Edition może zostać zainstalowany na hoście wirtualizacyjnym w celu realizacji zadań administracyjnych lub testowych. Nie uwzględniają jednak faktu, że host fizyczny może zostać zakwalifikowany jako środowisko produkcyjne wyłącznie dlatego, że uruchamia maszyny wirtualne wykonujące produkcyjne obciążenia.

Nielicencjonowane komponenty SQL Server uruchamiane na oddzielnych serwerach

W wielu organizacjach proces licencjonowania SQL Server koncentruje się wyłącznie na silniku bazodanowym (Database Engine). Tymczasem środowiska SQL Server bardzo często obejmują również dodatkowe komponenty, takie jak SQL Server Integration Services (SSIS), SQL Server Reporting Services (SSRS) czy usługi analityczne SQL Server Analysis Services (SSAS) wykorzystywane do budowy modeli OLAP i rozwiązań Business Intelligence. To właśnie te instalacje są jednym z częściej pomijanych obszarów podczas analiz zgodności licencyjnej.

Najczęstszy problem pojawia się w sytuacji, gdy organizacja instaluje dodatkowe komponenty SQL Server na odrębnych serwerach w celu rozdzielenia obciążeń lub zwiększenia wydajności środowiska. Przykładowo silnik bazodanowy może działać na jednym serwerze, podczas gdy usługi raportowe, integracyjne lub analityczne zostały wdrożone na innych maszynach fizycznych lub wirtualnych. W wielu przypadkach organizacja zakłada, że skoro baza danych została już prawidłowo licencjonowana, pozostałe komponenty są automatycznie objęte tym samym zakresem licencyjnym.

Takie podejście jest błędne. Z perspektywy licencjonowania Microsoft każdy serwer uruchamiający komponenty SQL Server wymaga odrębnej analizy licencyjnej. Sam fakt, że usługa Integration Services, Reporting Services lub Analysis Services współpracuje z już licencjonowaną bazą danych, nie oznacza automatycznie, że może zostać uruchomiona bez odpowiednich licencji na serwerze, na którym została zainstalowana.

Błędna interpretacja zasad licencjonowania SQL Server 2022

W przypadku SQL Server 2022 licencjonowanie pojedynczej maszyny wirtualnej w modelu Per Core jest dostępne dla licencji subskrypcyjnych oraz licencji objętych aktywnym Software Assurance. Jednym z najczęstszych błędów jest założenie, że każdą licencję SQL Server można przypisać do maszyny wirtualnej i liczyć wyłącznie jej vCPU.

W praktyce oznacza to, że przy analizie środowiska trzeba sprawdzić nie tylko liczbę vCPU, ale również:

• edycję i wersję SQL Server,
• rodzaj posiadanej licencji,
• status Software Assurance lub subskrypcji,
• liczbę vCPU przypisanych do każdej VM,
• hosty, na których VM może być uruchamiana,
• możliwość migracji VM pomiędzy hostami,
• zasady przypisania licencji do serwerów i farm serwerowych.

Dlatego podczas audytu trzeba przeanalizować całą topologię środowiska, a nie tylko konfigurację samej maszyny wirtualnej.

Najważniejsze wnioski

Najwięcej błędów związanych z SQL Server nie wynika z braku licencji, lecz z niewłaściwego przypisania ich do infrastruktury oraz błędnej interpretacji zasad licencjonowania. W środowiskach zwirtualizowanych szczególnego znaczenia nabiera analiza architektury, planowanych migracji i zakresu przysługujących praw licencyjnych. Najczęstszą przyczyną niezgodności wykrywanych podczas audytu nie jest brak licencji, lecz ich niewłaściwe wykorzystanie.

Jak uniknąć błędów licencyjnych Microsoft?

Najlepszym sposobem na ograniczenie ryzyka jest regularne zarządzanie licencjami, a nie działania podejmowane dopiero po otrzymaniu informacji o planowanej kontroli.

• Regularnie aktualizuj inwentaryzację.
• Dokumentuj wszystkie zmiany infrastruktury.
• Analizuj wpływ zmian przed ich wdrożeniem.
• Regularnie weryfikuj zgodność licencyjną.

Dobre praktyki zarządzania licencjami Microsoft

Organizacje, które skutecznie zarządzają licencjami, najczęściej wdrażają kilka prostych zasad:

• wyznaczają właściciela procesu licencyjnego,
• prowadzą centralny rejestr licencji,
• dokumentują wszystkie zmiany infrastruktury,
• analizują wpływ nowych projektów na licencjonowanie,
• regularnie szkolą administratorów i osoby odpowiedzialne za zakupy IT,
• okresowo przeprowadzają audyty zgodności.

Takie podejście nie tylko ogranicza ryzyko audytowe, ale również pozwala lepiej planować inwestycje w infrastrukturę oraz uniknąć kosztownych zakupów wykonywanych pod presją czasu.