SQL Server – Jak dobrać właściwy model licencjonowania (CORE czy CAL)?

Wprowadzenie

Wybór właściwego modelu licencjonowania Microsoft SQL Server jest kluczowy dla zapewnienia legalności (compliance) oraz optymalizacji kosztów w organizacji. Dylemat „Core czy CAL” dotyczy tego, czy lepiej licencjonować serwer baz danych na podstawie rdzeni procesora (tzw. licencjonowanie na rdzeń, ang. Per Core) czy w modelu serwer + dostęp klienta (Server + CAL, ang. Server + Client Access License). Decyzja ta ma ogromne znaczenie dla integratorów IT, instytucji publicznych i firm biznesowych – każdy z tych podmiotów może mieć inne potrzeby i uwarunkowania. W niniejszym artykule przyjrzymy się różnicom między tymi modelami, omówimy typowe błędy przy zakupie licencji SQL Server oraz wyjaśnimy kwestie zgodności licencyjnej. Przeanalizujemy także ograniczenia poszczególnych edycji (Express i Standard) oraz czynniki wpływające na dobór modelu, takie jak liczba użytkowników, środowiska wirtualne, liczba rdzeni i dostęp zewnętrzny. Całość uzupełnimy eksperckimi poradami, dlaczego w procesie doboru licencji warto zaangażować doświadczonego architekta IT.

Uwaga: Softium koncentruje się na sprzedaży tradycyjnych licencji wieczystych (np. w programach Microsoft Volume Licensing) i nie oferuje licencji w modelu CSP (Cloud Solution Provider). Poniższe rozważania dotyczą więc głównie licencji wieczystych dostępnych w kanałach takich jak OEM, OLP/Volume czy Retail. Wybór odpowiedniego modelu licencjonowania jest na tyle złożony, że warto skorzystać z pomocy ekspertów – w artykule znajdziesz wskazówki, a w razie wątpliwości skontaktuj się z naszymi ekspertami Softium.pl, którzy pomogą dobrać najkorzystniejsze rozwiązanie dla Twojej organizacji.

Modele licencjonowania SQL Server: Core vs. Server + CAL

Microsoft SQL Server oferuje dwa główne modele licencjonowania: na rdzeń (Per Core) oraz Serwer + CAL (Server + Client Access License). Każdy z nich charakteryzuje się odmiennym podejściem do licencjonowania użytkowania serwera baz danych:

• Licencjonowanie na rdzeń (Core-Based Licensing) – w tym modelu wykupuje się licencje na każdy rdzeń procesora serwera, na którym uruchomiony jest SQL Server. Nie są potrzebne oddzielne licencje dostępowe dla użytkowników ani urządzeń. Model „Per Core” zapewnia nieograniczoną liczbę użytkowników mogących korzystać z serwera – opłata zależy wyłącznie od mocy obliczeniowej (liczby rdzeni CPU). Licencje na rdzenie są sprzedawane w pakietach po 2 rdzenie i należy pokryć licencjami wszystkie fizyczne rdzenie procesora serwera (przy czym Microsoft wymaga wykupienia minimum 4 licencji na rdzeń na każdy fizyczny procesor serwera) (Microsoft SQL Server 2022 ). Oznacza to, że nawet jeśli procesor ma mniej niż 4 rdzenie, i tak trzeba wykupić licencje na cztery rdzenie (taka minimalna jednostka). Przykładowo, dla serwera z 2 procesorami 8-rdzeniowymi należy nabyć 16 licencji (2×8, sprzedawanych po 2 sztuki, czyli 8 pakietów licencji 2-rdzeniowych). W środowiskach zwirtualizowanych można licencjonować rdzenie przydzielone maszynom wirtualnym zamiast całemu fizycznemu serwerowi – również z zachowaniem minimum 4 rdzeni na każdą maszynę wirtualną (Microsoft SQL Server 2022 ). Model per Core obowiązuje obecnie dla edycji Standard (alternatywnie do CAL) oraz jedyny dostępny dla edycji Enterprise.
• Licencjonowanie Server + CAL (Serwer plus licencje dostępowe) – ten model wymaga posiadania licencji serwerowej na każdy uruchomiony serwer SQL (fizyczny lub wirtualny) oraz odpowiedniej liczby licencji dostępowych CAL dla użytkowników lub urządzeń korzystających z tego serwera. Skrót CAL oznacza Client Access License, czyli licencję dostępu klienckiego. Każdy użytkownik lub każde urządzenie, które łączy się z instancją SQL Server, musi posiadać ważną licencję CAL (chyba że dostęp jest anonimowy/publiczny – o czym dalej). Licencję CAL nie instalujemy na serwerze; jest to dokument/prawo dostępu dla konkretnego użytkownika bądź urządzenia. W ramach tego modelu trzeba zatem policzyć wszystkich uprawnionych użytkowników (lub urządzenia) i nabyć dla nich licencje CAL, a dodatkowo posiadać co najmniej jedną licencję na sam serwer SQL. Model Serwer+CAL jest dostępny tylko dla edycji SQL Server Standard – nowsze edycje Enterprise nie oferują tego modelu (Enterprise po 2012 roku jest wyłącznie per Core) (Microsoft SQL Server 2022 Licensing Guide and Training). Licencje CAL mogą być dwojakiego rodzaju: CAL na użytkownika (User CAL – przypisywana do konkretnej osoby, pozwalającej jej na dostęp z wielu urządzeń) lub CAL na urządzenie (Device CAL – przypisana do urządzenia, które może być używane przez wielu użytkowników). Wybór typu CAL zależy od charakteru środowiska – np. w biurze, gdzie każdy pracownik korzysta z własnego komputera i często również z telefonu, praktyczniejsza jest licencja CAL per użytkownik; z kolei w scenariuszach, gdzie wielu pracowników korzysta z jednego stanowiska (np. różne zmiany przy jednym terminalu), korzystniejsza bywa CAL na urządzenie.

Różnice i porównanie modeli

Oba powyższe modele zaspokajają ten sam cel – legalne korzystanie z serwera SQL – ale różnią się sposobem kalkulacji kosztów i zastosowaniem w zależności od sytuacji:

• Koszt a skala użytkowników – Model Serwer + CAL opłaca się typowo w środowiskach, gdzie liczba użytkowników lub urządzeń jest niewielka i stabilna. Przykładowo, jeśli baza danych ma obsługiwać kilkanaście osób w małej firmie lub departamencie, zakup jednej licencji serwerowej Standard plus np. 15 CAL może być znacznie tańszy niż licencjonowanie np. 8 rdzeni serwera. Natomiast model per Core zyskuje przewagę ekonomiczną przy dużej liczbie użytkowników lub trudnych do policzenia klientach. Gdy z bazy korzystają setki osób (albo nieograniczona liczba klientów, np. w aplikacji internetowej), sumaryczny koszt koniecznych CAL mógłby przekroczyć koszt licencji na rdzenie. Wtedy opłaca się kupić licencje na rdzenie i nie martwić się liczeniem dostępu każdego użytkownika. Regułą często cytowaną jest, że dla małych i średnich firm model Server+CAL bywa bardziej ekonomiczny, zaś dla dużych organizacji korzystniejszy okazuje się model na rdzeń (Wyjaśnienie licencjonowania SQL Server: CAL, licencja na rdzenie). Oczywiście wszystko zależy od konkretnych liczb – granica opłacalności przesuwa się wraz z cennikiem i warunkami danego klienta – dlatego zawsze warto wykonać kalkulację dla obu opcji.
• Ograniczenia co do edycji i wersji – Edycja SQL Server Standard może być licencjonowana na dwa sposoby (Core albo Server+CAL), dając elastyczność wyboru. Z kolei SQL Server Enterprise (przeznaczony do największych wdrożeń) od lat dostępny jest wyłącznie w modelu na rdzeń – nie wymaga i nie pozwala na użycie CAL. W praktyce więc dylemat „Core vs CAL” dotyczy głównie sytuacji, gdy rozważamy użycie edycji Standard. Jeśli potrzeby techniczne wymuszają edycję Enterprise (np. ze względu na funkcje tylko w Enterprise lub potrzebę nieograniczonej virtualizacji), wybór modelu jest automatycznie rozwiązany (tylko core-based). Natomiast SQL Server Express i Developer to osobne przypadki: Express jest darmowy (o jego ograniczeniach niżej), a Developer jest bezpłatny do celów testów i programowania, ale nie może być używany w produkcji. Te edycje nie wchodzą w modele komercyjne Core/CAL, choć ich obecność w organizacji też musi być uwzględniona w kontekście compliance.
• Sposób liczenia i zarządzania licencjami – Modele różnią się podejściem do administrowania licencjami. W modelu per Core istotna jest dokumentacja dotycząca przypisania licencji do serwera z określoną liczbą rdzeni. Trzeba pilnować, by przy rozbudowie sprzętu dokupić dodatkowe licencje, jeśli zwiększa się liczba rdzeni (np. migracja na nowy serwer z większą liczbą CPU). W modelu CAL natomiast wyzwaniem jest śledzenie, czy każdy użytkownik/urządzenie mają swoją licencję dostępową i czy nie przekraczamy posiadanej puli. W razie audytu należy wykazać, że posiadamy wystarczającą liczbę licencji CAL na wszystkich realnych użytkowników systemu. Istotne jest też rozróżnienie, że licencje CAL są przypisane do firmy (organizacji), a nie do konkretnego serwera – jeśli firma ma wiele serwerów SQL (Standard) i wykupi odpowiednią liczbę CAL, to ci licencjonowani użytkownicy mogą legalnie korzystać z dowolnego z tych serwerów. CAL nie przypina się do jednego serwera, tylko do osoby/urządzenia w kontekście całej infrastruktury SQL danej organizacji. Dzięki temu mając np. dwa serwery SQL Standard (np. produkcyjny i testowy), użytkownik posiadający jedną licencję User CAL może korzystać z obu. Jednakże należy posiadać osobną licencję serwerową na każdy z tych serwerów.
• Dostęp zewnętrzny – Bardzo ważna różnica praktyczna: model Server+CAL z definicji licencjonuje dostępy „wewnętrzne” (pracowników lub urządzenia wewnątrz organizacji). Jeśli z SQL Server mają korzystać także użytkownicy zewnętrzni (np. klienci spoza firmy łączący się do bazy danych poprzez aplikację, partnerzy biznesowi, użytkownicy publicznej strony WWW korzystającej z bazy itp.), model CAL staje się problematyczny. Licencje CAL nie obejmują gości spoza organizacji – są przeznaczone dla pracowników firmy (lub ewentualnie podmiotów powiązanych w ramach jednego przedsiębiorstwa). W scenariuszu udostępniania baz danych publicznie lub zewnętrznie nie da się wykupić CAL dla anonimowych czy niesprecyzowanych użytkowników. Microsoft przewiduje tutaj dwa rozwiązania: zakup tzw. External Connector License (dla niektórych serwerów, choć dla SQL Server konkretnie tradycyjnie zalecano raczej model per Core) lub po prostu przejście na model licencjonowania na rdzeń, gdzie nie ma znaczenia kto się łączy – ważne jest, że serwer jest licencjonowany na moc obliczeniową i może obsłużyć dowolnych użytkowników. Dlatego jeżeli planujemy wystawić usługi bazodanowe dla użytkowników zewnętrznych (np. klient logujący się do naszego systemu ERP/SaaS opartego o SQL), model na rdzeń będzie jedyną rozsądną opcją zapewniającą zgodność licencyjną.
• Skalowalność i przyszły wzrost – Wybierając model licencjonowania, warto patrzeć w przyszłość. Jeśli zakładamy, że system może znacząco się rozwinąć (np. znaczny przyrost liczby użytkowników lub zwiększenie mocy serwera), warto uwzględnić te zmiany już w planie licencyjnym. Model CAL może być opłacalny przy obecnych 20 użytkownikach, ale czy nadal będzie, gdy użytkowników będzie 100? Z drugiej strony, zakup licencji na rdzenie dla bardzo wydajnego serwera może dziś wydawać się kosztowny, ale jeśli docelowo z systemu skorzysta cała organizacja, może to być inwestycja z perspektywą. Microsoft daje pewną elastyczność – licencje CAL dokupujemy w miarę potrzeb, licencje Core również można dokupywać przy rozbudowie (byle przed użyciem dodatkowych rdzeni). Niemniej zmiana modelu w trakcie używania danego systemu może nie być prosta (np. przejście z CAL na Core często oznacza zupełnie nowy zakup licencji core i “porzucenie” dotychczasowych CAL, co generuje duży koszt). Dlatego wybór modelu na starcie projektu ma długofalowe konsekwencje i powinien być dokonany z pełną świadomością przyszłych potrzeb.

Podsumowując, model Serwer + CAL jest zwykle korzystny przy mniejszej skali i zamkniętym gronie znanych użytkowników (wewnętrznych), natomiast model per Core sprawdza się, gdy użytkowników jest wielu, nie sposób ich wygodnie policzyć lub zapewniamy dostęp dla osób spoza organizacji. Niezależnie od wyboru, obie opcje muszą być użyte zgodnie z zasadami licencjonowania Microsoft – w kolejnych sekcjach omówimy typowe błędy i zasady compliance, które pomogą uniknąć kosztownych pomyłek.

Typowe błędy przy zakupie licencji SQL Server

Zakup licencji SQL Server bywa skomplikowany, a na rynku krąży wiele mitów i pułapek. Oto kilka najczęstszych błędów popełnianych przez firmy i integratorów przy licencjonowaniu SQL Server:

• Niedoszacowanie liczby potrzebnych licencji CAL – Częstym błędem jest zakup zbyt małej liczby licencji dostępowych CAL w stosunku do rzeczywistej liczby użytkowników lub urządzeń korzystających z serwera. Np. firma kupuje 10 CAL, bo tylu użytkowników początkowo zgłoszono, ale pomija fakt, że baza jest również wykorzystywana przez dodatkowe procesy, usługi lub że dostęp ma więcej pracowników (np. dział raportowy korzysta sporadycznie, ale jednak korzysta – też potrzebuje licencji CAL!). Innym scenariuszem jest pominięcie tzw. pośrednich użytkowników: jeżeli SQL Server jest używany jako back-end dla innego systemu (np. ERP, system księgowy) to często wszyscy użytkownicy tego systemu w tle łączą się z SQL – każdy z nich powinien mieć CAL, nawet jeśli bezpośrednio nie loguje się do SQL Server. Brak wystarczającej liczby CAL wychodzi zwykle na jaw dopiero podczas audytu lub rozbudowy systemu, co stawia firmę przed nagłą koniecznością dokupienia brakujących licencji pod presją czasu.
• Licencjonowanie w modelu CAL mimo niekwalifikujących się użytkowników – Jak wspomniano, licencje CAL formalnie przeznaczone są dla pracowników/licencjonowanych użytkowników wewnętrznych. Czasami firmy próbują objąć tym modelem również użytkowników zewnętrznych (np. klientów), co nie jest zgodne z zasadami licencjonowania. Przykładowo, jeśli firma udostępnia aplikację webową z bazą SQL i stara się wykupić Device CAL na “serwer pośredniczący” albo jakiegoś użytkownika-techniczne konto, by obsłużyć wielu klientów, to nie spełni to wymogów licencyjnych – każdy klient zewnętrzny też musiałby mieć CAL, co jest niewykonalne organizacyjnie. Błędem jest zakładanie, że model CAL pokryje scenariusze dostępu publicznego – do takich zastosowań należy wybrać licencjonowanie na rdzeń.
• Zapominanie o licencjonowaniu środowisk testowych / zapasowych – Kolejnym częstym uchybieniem jest brak licencji na środowiska inne niż produkcyjne. Standardowa licencja komercyjna SQL Server uprawnia do uruchomienia jednej instancji produkcyjnej na danym serwerze (chyba że licencja obejmuje więcej poprzez np. prawa wirtualizacyjne Enterprise). Jeśli firma posiada środowisko testowe, szkoleniowe lub serwer zapasowy (stand-by) do celów DR (Disaster Recovery), to również powinno być ono licencjonowane, chyba że korzysta się z uprawnień wynikających z Software Assurance (SA) – np. prawo do jednej pasywnej instancji zapasowej bez dodatkowej opłaty. Często jednak firmy nie mają Software Assurance, a mimo to uruchamiają drugą instancję SQL na serwerze DR bez licencji – jest to niezgodne z licencją i w razie kontroli będzie traktowane jako wykorzystanie nieopłaconego oprogramowania. Podobnie środowiska testowe wymagają licencji, chyba że używamy edycji Developer (dostępnej bezpłatnie tylko do testów, nie produkcji). Błędem bywa używanie edycji Developer w celach innych niż deweloperskie – np. do taniego hostowania mniej ważnej bazy produkcyjnej – co również łamie warunki licencji.
• Niezgodność wersji licencji i oprogramowania – Czasem klienci kupują licencje na starszą edycję (np. SQL Server 2016 Standard CAL), a instalują nowszą wersję (np. SQL 2019), sądząc, że licencja działa wstecz lub odwrotnie. Licencja uprawnia do używania określonej wersji oprogramowania lub starszych (tzw. downgrade jest dozwolony), ale nie odwrotnie – posiadanie licencji na SQL 2017 nie legalizuje użycia SQL 2019. Jeśli chcemy użyć nowszej wersji niż posiadana licencja, musimy dokonać aktualizacji licencji (np. w ramach Software Assurance lub zakupu nowej licencji). Innym przykładem jest mylenie edycji – np. ktoś kupuje licencję Standard (tańszą) a instaluje Enterprise, co oczywiście jest nielegalne (chyba że posiada prawo do tzw. down-edition, co generalnie nie jest dozwolone w SQL Server poza szczególnymi przypadkami licencji objętych SA). W skrócie: edukujmy klientów, że licencja musi odpowiadać co do wersji i edycji używanemu oprogramowaniu, inaczej mówimy o klasycznym przypadku niezgodności licencyjnej.
• Błędne licencjonowanie w środowiskach wirtualnych – Wirtualizacja wprowadza dodatkowy poziom komplikacji. Typowe błędy to np. założenie, że wystarczy jedna licencja SQL Standard Server na hosta, aby pokryć wiele maszyn wirtualnych – niestety nie, licencja Server+CAL dotyczy jednej instancji (jednego środowiska OSE). Jeśli na jednym hoście fizycznym uruchamiamy trzy oddzielne VM z SQL Standard (bez licencji core), to każdy VM wymaga osobnej licencji serwerowej Standard + odpowiednią liczbę CAL. Próba „oszczędzenia” i użycia jednej licencji Standard na wiele VM jest niezgodna z licencją. Alternatywą jest przejście na licencjonowanie na rdzeń – tu można podejść dwojako: licencjonować każdą maszynę wirtualną osobno na podstawie liczby przydzielonych jej rdzeni (co czasem jest korzystne, gdy VM ma mało vCPU), albo – w przypadku edycji Enterprise – licencjonować cały host fizyczny (wszystkie rdzenie) co przy aktywnym Software Assurance daje prawo do uruchamiania nielimitowanej liczby VM na tym hoście (Editions and supported features of SQL Server 2019 – SQL Server | Microsoft Learn) (Editions and supported features of SQL Server 2019 – SQL Server | Microsoft Learn) (dotyczy to tylko Enterprise + SA, Standard nie ma prawa nieograniczonej wirtualizacji). Błędem bywa też nieprzestrzeganie zasady przypisania licencji na 90 dni – wedle zasad Microsoft, licencję (czy to Core, czy serwerową) przypisuje się do konkretnego serwera/hosta i nie można przenosić jej na inny serwer częściej niż raz na 90 dni (chyba że sprzęt uległ awarii). W środowisku klastrowym bez SA, jeśli VM migruje na inny host, to licencja (przypisana do pierwotnego hosta) formalnie nie może „podążyć” za nią przed upływem 90 dni – aby pokryć scenariusz dynamicznego przenoszenia maszyn (Live Migration, VMware vMotion itp.), trzeba mieć Software Assurance zapewniające tzw. License Mobility. Często firmy o tym nie wiedzą, zakładając że licencja „podąża” automatycznie – co może być uznane za naruszenie licencji w razie audytu.
• Kupowanie licencji z niepewnych źródeł lub w niewłaściwej formie – To również warto odnotować: rynek licencji Microsoft jest pełen ofert „specjalnych” – np. odsprzedaży używanych licencji, tanich kluczy OEM, czy licencji typu CSP sprzedawanych bez właściwego kanału. Typowym błędem jest zakup licencji OEM myśląc, że można je dowolnie przenieść na inny sprzęt (OEM są przypisane do sprzętu, na którym zostały pierwotnie zainstalowane – i dotyczy to również OEM SQL Server, choć ta forma jest rzadka dla SQL). Inny przykład to nabywanie licencji w programie CSP bez pełnej świadomości warunków – np. licencje CSP (subskrypcyjne) mogą mieć inne prawa niż tradycyjne licencje wieczyste. Zdarzają się też oszustwa – sprzedaż kluczy MSDN lub edukacyjnych jako legalnych komercyjnych. Zawsze upewnij się, że licencje pochodzą z zaufanego źródła i są właściwe dla twojego typu organizacji (np. licencje academic tylko dla uprawnionych instytucji edukacyjnych, licencje rządowe tylko dla kwalifikujących się podmiotów publicznych itp.). W razie kontroli liczy się ważność licencji, a nie fakt, że „ktoś sprzedał”. Dlatego współpracuj z zaufanym partnerem, takim jak Softium, który dostarcza legalne oprogramowanie i doradzi odpowiednią formę licencji (np. licencje grupowe Open, umowy EA, czy CSP – przy czym Softium, przypomnijmy, nie sprzedaje CSP, ale wskaże inne dostępne opcje).
• Niedopasowanie edycji SQL Server do potrzeb – Na koniec warto wspomnieć błąd, który nie tyle jest „nielegalny”, co może być kosztowny: wybór niewłaściwej edycji SQL Server. Czasem klient kupuje Enterprise Edition, podczas gdy Standard w pełni by wystarczył – przepłacając ogromnie za funkcje, których nie użyje. Bywa i odwrotnie: ktoś decyduje się na Standard, ale potrzebuje funkcjonalności, której brak w Standard (np. zaawansowane opcje wysokiej dostępności, większa skalowalność, Enteprise-only features), przez co próbuje „obejść” ograniczenia Standardu kosztem stabilności lub bezpieczeństwa. Niewłaściwa edycja połączona z niewłaściwym modelem licencji może spowodować albo niepotrzebne wydatki, albo ograniczenia w rozwoju systemu. Dlatego zawsze należy dokładnie przeanalizować wymagania techniczne i licencyjne – i tutaj ponownie kłania się rola eksperckiego doradztwa, zanim wydamy budżet na licencje.

Zgodność licencyjna (compliance) i konsekwencje jej braku

Compliance licencyjny to nic innego jak zgodność używanego oprogramowania z posiadanymi licencjami. Mówiąc wprost: czy nasz stan faktyczny (zainstalowane i używane instancje SQL Server oraz liczba ich użytkowników) jest w pełni pokryty przez stan posiadania licencji. Utrzymanie zgodności licencyjnej jest obowiązkiem prawnym każdej organizacji – oprogramowanie jest chronione prawem autorskim, a licencja to warunek legalnego używania. Brak compliance, czyli używanie SQL Server bez odpowiedniej licencji (bądź ponad zakres licencji), to łamanie prawa, które może skutkować poważnymi konsekwencjami.

W praktyce compliance w kontekście SQL Server oznacza m.in.:

• Posiadanie odpowiedniej liczby licencji (Core lub CAL + Server) dla każdego serwera i użytkownika zgodnie z modelami opisanymi wcześniej.
• Przypisanie licencji do właściwych środowisk (np. czy nie przenieśliśmy licencji na inny serwer bez uprawnień, czy nie używamy jednej licencji Standard CAL na kilka serwerów itp.).
• Używanie właściwych wersji i edycji – tzn. nie korzystamy z funkcji wykraczających poza zakupioną edycję, ani z wersji na które nie mamy prawa.
• Dokumentowanie i ewidencjonowanie licencji – aby móc wykazać podczas ewentualnej kontroli, że jesteśmy legalni.

Co grozi za brak compliance? Microsoft (lub organizacje przez niego upoważnione, np. audytorzy z firm trzecich czy organizacja BSA – Business Software Alliance) ma prawo skontrolować firmę pod kątem legalności oprogramowania. Kontrole takie w Polsce się zdarzają, szczególnie w średnich i dużych podmiotach oraz sektorze publicznym. Jeśli w wyniku audytu okaże się, że firma używa SQL Server bez odpowiednich licencji (np. ma uruchomione instancje bez licencji, za mało CAL w stosunku do użytkowników, nieopłacone rdzenie itp.), konsekwencje mogą obejmować:

• Konieczność dokupienia brakujących licencji z natychmiastową płatnością – zazwyczaj firma zostaje zobowiązana do zakupu brakujących licencji (często po cenach katalogowych) za cały okres nielegalnego używania. Np. jeśli przez 2 lata używano 4 rdzeni bez licencji, trzeba będzie wykupić licencje na te rdzenie retroaktywnie, często wraz z dopłatą za okres używania.
• Kary umowne lub finansowe – w skrajnych przypadkach producent może domagać się kar za naruszenie umowy licencyjnej. W Polsce najczęściej kończy się na obowiązku legalizacji oprogramowania i zapłacie za brakujące licencje, ale formalnie naruszenie licencji jest złamaniem prawa autorskiego, co mogłoby wiązać się nawet z odpowiedzialnością cywilną, a gdyby udowodniono świadome piractwo na dużą skalę – teoretycznie także karne. Dla instytucji publicznych wyjście na jaw nielegalnego oprogramowania może wiązać się z sankcjami administracyjnymi i na pewno z utratą wizerunku oraz zaufania.
• Utrata rabatów i przywilejów – firmy, które wpadają na niezgodność w audycie, tracą często możliwość negocjacji lepszych warunków licencyjnych (np. w ramach kolejnych umów Enterprise Agreement). Zamiast tego są „na cenzurowanym” i muszą udowodnić poprawę.
• Koszty operacyjne i przestój – niekiedy w razie stwierdzenia poważnych naruszeń firma może zostać zmuszona do czasowego wyłączenia nielegalnych instancji albo szybko migrować na legalne rozwiązania. To może powodować przerwy w działaniu systemów, gorączkowe prace działu IT, dodatkowe nieplanowane wydatki. Zamiast spokojnie budżetować upgrade czy rozbudowę, robi się kryzysowa sytuacja pod presją audytora.
• Zachwianie zaufania – szczególnie dla integratorów IT lub dostawców usług (MSP), wykrycie niezgodności licencyjnej może podważyć zaufanie klientów. Jeśli integrator utrzymuje klientowi środowisko i okaże się, że doradził błędne licencjonowanie – klient ma pełne prawo być niezadowolony, a reputacja integratora cierpi. Dlatego tak ważne jest, by już na etapie planowania architektury i zakupów zadbać o pełną zgodność z licencjami.

Z tych powodów compliance to nie jest tylko kwestia formalna – ma realne przełożenie na ryzyko finansowe i operacyjne firmy. Dobra wiadomość jest taka, że przy odpowiednim podejściu można compliance utrzymać bez problemu. Kluczem jest wiedza i systematyczność: śledzenie co i gdzie jest zainstalowane, ile użytkowników korzysta z systemu, jakie licencje posiadamy i do czego one uprawniają. W dużych organizacjach pomaga w tym SAM (Software Asset Management) – procesy i narzędzia do zarządzania zasobami oprogramowania. W mniejszych firmach wystarczy świadome podejście i konsultacje z ekspertami od licencjonowania przed większymi zmianami w infrastrukturze.

Warto też na bieżąco aktualizować się z polityką licencyjną Microsoft, bo ta z czasem ulega modyfikacjom (np. pojawienie się subskrypcyjnego modelu CSP, zmiany w prawach licencji przy przenoszeniu do chmury itd.). Nieświadomość nie chroni przed karą – dlatego lepiej dmuchać na zimne i regularnie przeprowadzać wewnętrzne audyty licencji lub zlecać przegląd specjalistom. Softium w ramach swoich usług doradczych pomaga klientom ocenić ich stan licencyjny i wskazać ewentualne luki, zanim zrobi to oficjalny audytor.

Ograniczenia edycji SQL Server Express i Standard

W kontekście doboru modelu licencjonowania warto również zrozumieć techniczne i funkcjonalne ograniczenia różnych edycji SQL Server, zwłaszcza bezpłatnej edycji Express oraz popularnej edycji Standard. Wybór między modelem Core a CAL często wiąże się z wyborem edycji, a niewłaściwa ocena możliwości edycji może prowadzić do błędnego planu licencyjnego. Poniżej omawiamy najważniejsze ograniczenia Express i Standard oraz ich wpływ na decyzje licencyjne.

SQL Server Express – darmowy, ale mocno ograniczony

SQL Server Express to darmowa edycja SQL Server, przeznaczona do zastosowań testowych, edukacyjnych, małych aplikacji lub wbudowania w aplikacje ISV. Choć atrakcyjna cenowo (0 zł), ma wbudowane ścisłe limity, które sprawiają, że nie nadaje się do średnich i dużych zastosowań produkcyjnych. Oto główne ograniczenia SQL Express:

• Maksymalny rozmiar bazy danych: 10 GB – pojedyncza baza danych w Express może mieć co najwyżej 10 GB danych (nie licząc plików log). Ta granica powoduje, że Express obsłuży tylko bardzo małe zbiory danych. Co prawda można tworzyć wiele oddzielnych baz po 10 GB i aplikacja może je wykorzystywać, ale to obejście jest skomplikowane i rzadko praktyczne. Limit 10 GB jest sztywny i po jego przekroczeniu baza po prostu przestaje przyjmować nowe dane, co dyskwalifikuje Express w poważniejszych systemach.
• Ograniczenie pamięci RAM: 1 GB – silnik bazy danych SQL Express może użyć maksymalnie ok. 1 GB pamięci RAM dla buforu danych (nieco więcej może zająć na potrzeby innych cache, ale generalnie wydajność jest limitowana przez ~1 GB pamięci operacyjnej). Nawet jeśli serwer fizyczny ma więcej RAM, instancja Express nie przydzieli sobie powyżej tego limitu. Oznacza to, że nie osiągniemy na Expressie wysokiej wydajności odczytu/zapisu danych, bo cache dyskowy jest minimalny. Dla porównania, Standard Edition potrafi użyć do 128 GB RAM (a Enterprise nawet terabajty, zależnie od sprzętu).
• Ograniczenie mocy CPU: 1 socket / 4 rdzenie maksymalnie – Express potrafi wykorzystać jednocześnie bardzo ograniczoną moc procesora. Może obsłużyć jeden fizyczny procesor (socket), a w ramach niego wykorzysta maksymalnie 4 rdzenie (nawet jeśli CPU ma więcej rdzeni, Express użyje tylko czterech). W praktyce jeśli zainstalujemy Express na nowoczesnym serwerze z 2 procesorami 10-rdzeniowymi, to i tak będzie on działał jak na 1 procesorze 4-rdzeniowym. Limit ten zapewnia, że Express służy głównie do lekkich zadań. Dodatkowo, brak jest funkcji obsługi wielowątkowości na szerszą skalę – Express nie oferuje parallel query processing na poziomie jak Standard/Enterprise, co ogranicza wydajność zapytań na dużych zbiorach danych.
• Brak niektórych usług i funkcjonalności – Express to jedynie podstawowy silnik baz danych. Nie zawiera SQL Server Agent (usługi automatyzacji zadań) – co oznacza, że nie da się na Expressie konfigurować zaplanowanych kopii zapasowych czy zadań ETL poprzez standardowe mechanizmy (trzeba stosować obejścia, np. zadania Windows lub narzędzia zewnętrzne). Ponadto Express nie oferuje zaawansowanych komponentów BI: brak Analysis Services, brak pełnej wersji Reporting Services (jest limitowana wersja w wariancie Express with Advanced Services), brak Machine Learning Services itp. Skalowalność i dostępność też są ograniczone – Express nie wspiera np. failover clusterów czy replikacji transakcyjnej jako wydawca (może być co najwyżej subskrybentem).
• Obsługa tylko podstawowych scenariuszy – Microsoft projektował Express z myślą o embeddowaniu w aplikacje i bardzo małych wdrożeniach. Dlatego licencyjnie Express jest darmowy niezależnie od liczby użytkowników, ale technicznie i wydajnościowo jest tak ograniczony, że jeżeli aplikacja staje się popularna lub krytyczna, to szybko wymaga migracji do edycji płatnych. Sam Microsoft wprost wskazuje, że gdy potrzeba więcej funkcji lub mocy, Express można płynnie uaktualnić do wyższych edycji SQL Server (Editions and supported features of SQL Server 2019 – SQL Server | Microsoft Learn). Innymi słowy, Express jest wabikiem do testów i startów, ale nie ucieknie się od licencji jeśli projekt się rozrośnie.

Z punktu widzenia licencjonowania, Express jest o tyle wygodny, że nie wymaga żadnych licencji (darmowy produkt). Często pojawia się pokusa, by wykorzystać Express zamiast płatnego Standardu właśnie w celu uniknięcia kosztów licencji. Jest to jednak podejście krótkowzroczne – jeśli dane przekroczą 10 GB lub system potrzebuje większej wydajności, staniemy przed nagłą koniecznością migracji na Standard/Enterprise, czyli koniecznością zakupu licencji. Co gorsza, migracja taka pod presją (bo np. baza stanęła z powodu limitu) może prowadzić do pośpiesznych decyzji licencyjnych i błędów compliance. Dlatego Express nadaje się tylko do bardzo ograniczonych zastosowań (np. mała stronka WWW, pojedynczy program do obsługi jednego działu, który na pewno nie urośnie powyżej limitów). W każdym poważniejszym przypadku lepiej od razu zaplanować użycie edycji Standard i właściwego modelu licencji, niż liczyć, że „jakoś to będzie” na Expressie.

SQL Server Standard – kompromis funkcjonalności i ceny, ale z pewnymi limitami

SQL Server Standard Edition jest najczęściej wybieraną edycją w średnich firmach i wielu instytucjach publicznych, gdyż oferuje solidny zestaw funkcji bazodanowych przy stosunkowo umiarkowanej cenie (w porównaniu do Enterprise). Edycja Standard może być licencjonowana zarówno w modelu Server+CAL, jak i per Core, co daje elastyczność finansową. Jednak Standard ma pewne ograniczenia (względem edycji Enterprise), o których trzeba pamiętać planując architekturę i licencje:

• Limit zasobów sprzętowych – SQL Standard nie skaluje się nieskończenie wraz ze sprzętem. Microsoft narzuca ograniczenie maksymalnie 4 gniazd CPU lub 24 rdzeni – wykorzystywanych przez jedną instancję SQL Standard (zawsze obowiązuje mniejsza z tych wartości) Oznacza to, że nawet jeśli zainstalujemy SQL Standard na serwerze z 32 rdzeniami, to jedna instancja użyje najwyżej 24 z nich (pozostałych 8 nie zwiększy mocy tej instancji). Podobnie w maszynie 8-socketowej użyje tylko 4 sockety. Ten limit dotyczy mocy obliczeniowej, nie licencji jako takiej – można posiadać licencje na wszystkie rdzenie (np. kupić per Core na 32 rdzenie), ale instancja i tak ponad 24 nie użyje. W kontekście licencyjnym warto o tym pamiętać: zakup licencji na rdzenie powyżej 24 dla jednej instancji Standard nie ma sensu wydajnościowo – lepiej wtedy rozważyć Enterprise. Standard ma też limit pamięci RAM – może wykorzystać do 128 GB RAM dla bufora danych (oraz dodatkowo do 32 GB dla funkcji in-memory OLTP i do 32 GB dla kolumnowych indeksów, jeśli są używane). Enterprise nie ma takich limitów (poza możliwościami systemu operacyjnego). Co prawda 128 GB RAM to dużo i wystarcza dla wielu zastosowań, ale dla bardzo dużych baz może być niewystarczające. Zatem, jeżeli system wymaga obsługi naprawdę wielkich wolumenów danych lub wielu rdzeni równolegle, Standard może okazać się „za mały” i trzeba zaplanować edycję Enterprise (ze wszystkimi tego licencyjnymi konsekwencjami, jak brak CAL i wysoka cena).
• Brak niektórych funkcjonalności klasy enterprise – Edycja Standard obsługuje większość podstawowych funkcji SQL Server (relacyjna baza danych, podstawowe indeksy, replikacja snapshot/transakcyjna jako subskrybent, podstawowe funkcje analityczne). Jednak niektórych zaawansowanych opcji brak. Przykładowo, Transparent Data Encryption (TDE) przed SQL 2019 było dostępne tylko w Enterprise (od SQL 2019 TDE jest już w Standard, co poszerzyło możliwości Standardu w zakresie bezpieczeństwa). Nadal jednak brakuje w Standard np. rozproszonych partycjonowanych widoków skalujących na wiele serwerów, zaawansowanych mechanizmów kompresji i wirtualizacji danych (np. Data Virtualization wprowadzona w SQL 2022 jest ograniczona), brak wielu zaawansowanych narzędzi tuningowych (np. Database Snapshot, inteligentna obsługa zapytań w pełnym zakresie działa lepiej w Enterprise). In-Memory OLTP działa w Standard z ograniczeniem 32GB na tabelę pamięciową. Klaster failover – Standard pozwala utworzyć klaster dwuwęzłowy (jeden aktywny, jeden pasywny) lub Basic Availability Group z dwoma replikami (jedna baza podstawowa, jedna wtórna). Enterprise pozwala na znacznie więcej – wiele replik, wiele baz w grupie dostępności, tryb czytelnym na replikach itp. Ograniczenia Standardu obejmują też brak niektórych usług BI: np. Analysis Services i Reporting Services co prawda są dostępne w Standard, ale np. Machine Learning Services (R, Python) działają w Standard, jednak z pewnymi ograniczeniami wydajnościowymi. Generalnie, jeśli projekt wymaga np. zaawansowanej analizy OLAP, ogromnej wydajności transakcyjnej czy skomplikowanych mechanizmów HA/DR, może wymusić to użycie Enterprise.
• Brak prawa do nieograniczonej wirtualizacji – Wspomnieliśmy to przy błędach licencjonowania, ale powtórzmy: tylko licencjonowanie Enterprise Edition z aktywnym Software Assurance daje możliwość uruchamiania dowolnej liczby instancji na serwerze/hypervisorze (tzw. unlimited virtualization rights) (Editions and supported features of SQL Server 2019 – SQL Server | Microsoft Learn). Standard Edition nawet z licencjami core na cały serwer nie daje prawa do nielimitowanych VM – każda dodatkowa instancja/VM wymaga kolejnej licencji (chyba że mieści się w ramach 1 fizycznego środowiska + 1 failover pasywny bez SA). Innymi słowy, jeśli planujemy hostować wiele maszyn wirtualnych z SQL Server, to przy Standard trzeba liczyć licencje per VM albo kupić licencje na rdzenie oddzielnie dla każdej VM – co bywa nieefektywne, gdy tych VM jest dużo. W takich scenariuszach często przechodzi się na Enterprise, licencjonuje host i korzysta z wielu VM. Zatem ograniczenia Standardu w obszarze licencyjnym są takie, że nie pozwala on na uproszczenie licencjonowania przy dużej konsolidacji – wtedy należy zmienić edycję.
• Cena i dostępność modeli – Standard jest droższy od Express (który jest darmowy) i znacznie tańszy od Enterprise. Dla rzędu wielkości: licencja SQL Server 2022 Standard (licencja serwerowa) kosztuje w przedziale kilku tysięcy zł, podczas gdy Enterprise Core (przeliczając na cały serwer) może to być dziesięciokrotność i więcej. Dlatego wiele firm siłą rzeczy wybiera Standard. Standard oferuje też wybór modelu licencji: można kupić licencję serwerową + CAL albo licencje na rdzenie. Enterprise nie daje takiego wyboru (tylko rdzenie). Warto pamiętać, że CAL do SQL Server są niezależne od CAL do Windows Server czy innych produktów – czasem mit polega na myśleniu, że „mamy już CALe do Windows, to SQL będzie objęty” – to nieprawda, potrzebne są dedykowane SQL CAL. Na szczęście, Microsoft utrzymuje kompatybilność CAL: np. licencja CAL SQL Server 2019 uprawnia do dostępu do serwera SQL 2022 (czyli nowszego) tylko jeśli jest objęta Software Assurance. Bez SA, CAL-e muszą być co najmniej takiej wersji jak serwer. W drugą stronę (dostęp do starszych wersji) CAL zawsze działają.

Podsumowując, edycja Standard to rozsądny kompromis dla wielu zastosowań, ale trzeba być świadomym jej limitów. Przy doborze modelu licencjonowania czasem edycja wymusza model – np. gdy okaże się, że potrzebujemy Enterprise (z powodów technicznych), wtedy automatycznie musimy iść w licencje core (i budżet na to). Albo odwrotnie: jeśli wiemy, że budżet nie pozwoli na Enterprise, musimy tak zaprojektować system, by zmieścił się w możliwościach Standard (np. pogodzić z limitem 24 rdzeni czy brakiem pewnych funkcji) i wtedy rozważyć czy CAL czy Core. Zawsze analizujemy łącznie aspekt techniczny (edycja) i licencyjny (model) – bo to dwie strony tej samej monety, decydujące o sukcesie projektu.

Czynniki wpływające na dobór modelu licencjonowania

Wybór między licencjami Core a Server+CAL nie może być dokonany w próżni – należy rozważyć szereg czynników związanych ze środowiskiem i sposobem użytkowania serwera SQL. Poniżej omawiamy kluczowe czynniki, które powinny zostać przeanalizowane przed podjęciem decyzji o modelu licencji:

Liczba użytkowników i urządzeń

Jednym z pierwszych pytań, jakie należy zadać, jest: ile unikalnych użytkowników (lub urządzeń) będzie korzystać z serwera baz danych? To fundamentalne kryterium, ponieważ bezpośrednio wpływa na opłacalność modelu CAL.

• Jeśli mamy do czynienia z niewielką, zamkniętą grupą użytkowników – na przykład baza danych ma służyć aplikacji używanej przez 10 pracowników działu finansów – to model Serwer + CAL może być bardzo ekonomiczny. Kupujemy jedną licencję SQL Standard na serwer i 10 licencji User CAL (lub Device CAL, jeśli to np. 10 komputerów dzielonych przez więcej osób). Sumaryczny koszt będzie zapewne niższy niż licencjonowanie na rdzeń, zwłaszcza gdy serwer fizyczny ma wiele rdzeni. Przykładowo, koszt 10 CAL może być rzędu kilkunastu tysięcy złotych, podczas gdy licencje na 8 rdzeni mogłyby kosztować kilkadziesiąt tysięcy – jest różnica.
• Jeżeli jednak liczba użytkowników idzie w dziesiątki lub setki, lub trudno ją dokładnie określić (np. wielu sporadycznych użytkowników, albo potencjalnie każdy pracownik firmy może kiedyś zajrzeć do systemu), wówczas koszt sumaryczny modelu CAL rośnie wykładniczo. Dla 100 użytkowników koszt 100 CAL + licencja serwerowa niemal na pewno przekroczy koszt licencji na typowy serwer 8-rdzeniowy w modelu core. Dodatkowo, administrowanie setkami licencji CAL (przypisywanie, kontrolowanie kto ma, a kto nie) staje się uciążliwe. W takich sytuacjach model Core jest wygodniejszy i często tańszy.
• Struktura organizacji również ma znaczenie: czy użytkownicy są w jednym dziale, czy to przekrojowo cała firma? Czy jest rotacja pracowników (każda nowa osoba wymaga nowej CAL, bo starej formalnie nie można „przekazać” chyba że stary pracownik odchodzi definitywnie)? Czy korzystają z wielu urządzeń (telefony, laptopy, stacje)? Jeśli tak, User CAL może być lepszy od Device CAL. Ale jeśli np. firma pracuje w trybie zmianowym i 3 osoby dzielą to samo stanowisko PC w różnych godzinach, to Device CAL jest efektywny kosztowo – 3 osoby na 1 CAL. Analiza stylu pracy jest ważna, by dobrać optymalnie typ CAL i ich liczbę.
• Nie zapominajmy także o użytkownikach pośrednich i automatycznych. Weźmy przykład: w firmie jest 5 analityków BI, którzy korzystają z narzędzia raportowego łączącego się z SQL Server. Czy potrzebujemy 5 CAL? Tak – każdy z nich to użytkownik końcowy. Ale co jeśli mamy proces integracyjny, gdzie inny serwer (aplikacja) łączy się do bazy? Samo konto serwisowe, przez które łączy się inna aplikacja, nie potrzebuje CAL – licencjonujemy osoby lub urządzenia które korzystają pośrednio czy bezpośrednio z danych. Zasada: każdy, kto czerpie z danych serwera SQL interaktywnie lub poprzez aplikacje, powinien być objęty licencją. Dlatego jeśli aplikacja ma 100 użytkowników, to mimo że do SQL łączy się tylko 1 konto serwisowe z aplikacji, realnie 100 osób korzysta z bazy i na tyle należałoby mieć CAL (chyba że przechodzimy na model Core).

Podsumowując, liczbę użytkowników zestawia się z kosztem na rdzeń: zazwyczaj przy kilkunastu lub kilkudziesięciu użytkownikach CAL są opłacalne, a powyżej pewnego punktu – różnego dla różnych cenników – lepiej wychodzi licencja core. Przy kalkulacji warto też uwzględnić przyszły wzrost użytkowników. Jeśli dziś jest 30, ale planujemy wdrożyć system w całej organizacji 300-osobowej, może warto od razu iść w licencje core, zamiast dokupować stopniowo CAL (co może finalnie kosztować więcej).

Środowisko zwirtualizowane (maszyny wirtualne)

Coraz więcej wdrożeń baz danych odbywa się na maszynach wirtualnych (VM) lub w środowiskach chmurowych. Wirtualizacja niesie ze sobą zalety elastyczności i lepszego wykorzystania zasobów, ale wpływa na sposób licencjonowania:

• Liczba instancji / VM: Jeśli planujesz uruchomić wiele instancji SQL Server (np. rozdzielić bazy na kilka maszyn wirtualnych dla izolacji lub lepszego zarządzania), musisz licencjonować każdą instancję osobno w modelu Server+CAL (każda VM z SQL Standard potrzebuje własnej licencji serwerowej Standard). W modelu Core masz dwie opcje: licencjonować każdą VM osobno na podstawie vCPU, lub licencjonować host. Dla edycji Standard, licencjonowanie hosta fizycznego na wszystkie rdzenie nie zwalnia z licencjonowania kolejnych VM – musiałbyś zakupić tyle licencji core paczek, ile potrzeba, aby pokryć sumę rdzeni używanych przez wszystkie VM (co praktycznie sprowadza się do tego samego, tylko może ułatwia kupno w pakietach). Dla edycji Enterprise z SA, licencjonując cały host zyskujesz prawo do nieograniczonej liczby VM – to scenariusz dla dużych środowisk, w których stoi host z kilkunastoma/kilkudziesięcioma rdzeniami i można tam konsolidować wiele baz (Enterprise + SA to jednak wysoki koszt, opłacalny gdy naprawdę tych instancji jest dużo).
• Przenoszenie obciążeń między hostami: W środowisku zwłaszcza VMware, Hyper-V Cluster itp., gdzie maszyny wirtualne mogą migrować między hostami (np. w razie awarii lub dla load balancing), licencjonowanie musi uwzględniać te ruchy. Jeśli mamy model CAL, to licencja serwerowa Standard jest przypisana do konkretnej maszyny wirtualnej – jej migracja na inny host nie zmienia nic, bo licencja „idzie” z VM (tu nie ma problemu, o ile architektura nie łamie innych zasad). W modelu per Core standardowo licencje przypisujemy do fizycznego hosta. Wyobraźmy sobie dwa hosty ESXi i klaster, a na nim VM z SQL. Aby być zgodnym, musimy licencje core przypisać do obydwu hostów (bo VM może być uruchomiona na jednym albo drugim). Microsoft dopuszcza tzw. License Mobility within Server Farms (jeśli mamy Software Assurance), co pozwala przenosić licencje między hostami w klastrze w czasie rzeczywistym. Jeśli jednak nie mamy SA, to każdy host, na którym może wylądować VM z SQL, musi być w pełni licencjonowany (lub przestrzegamy zasady 90 dni – nie przenosimy VM częściej niż raz na 90 dni między licencjonowanymi hostami). Dla wielu organizacji to ważny aspekt: czy planujemy klaster HA/DR? Jeśli tak, model core + SA może być wręcz wymagany, by legalnie korzystać z mobilności. W modelu CAL też da się to obejść (np. druga licencja serwerowa na zapasowy serwer i manualne trzymanie się 90 dni), ale generalnie im bardziej złożona wirtualizacja, tym bardziej skłaniamy się ku licencjonowaniu core z SA.
• Małe maszyny vs duży host: Wirtualizacja często pozwala stawiać kilka mniejszych VM zamiast jednego dużego serwera. Przykład: mamy fizyczny serwer 16 rdzeni, stawiamy na nim 4 VM, każda dostaje 4 vCPU, i na każdej instancja SQL Standard obsługująca inny dział. W modelu Server+CAL kupimy 4 licencje Standard (po jednej na VM) + CALe. W modelu Core możemy kupić licencje na 4 rdzenie dla każdej VM, czyli 4× (4 rdzenie licencji) = 16 rdzeni – de facto tyle, ile ma host. Kosztowo na to samo wyjdzie, co licencjonować host 16 rdzeni (tyle że Standard nie da unlimited VM). Ale: Jeśli te VM są lekkie i np. mogłyby działać na 2 rdzeniach każda, to moglibyśmy licencjonować np. każdą VM tylko na 2 rdzenie (pamiętając o minimum 4 licencje per VM – tu ważne: Microsoft wymaga minimum 4 licencje na VM też, więc nawet jak VM ma 2 vCPU, i tak trzeba wykupić 4 licencje na rdzeń). Czyli minimalny pakiet to 4 core licencje per VM. Tak czy inaczej, przy wielu małych VM Standard model core traci część sensu przez to minimum. Model CAL w takiej sytuacji może być tańszy (4 licencje Standard serwerowe mogą kosztować mniej niż 4×4 core licencji Standard). Widzimy więc, że kluczowa jest liczba VM i przydzielonych vCPU – gdy VM jest sporo, z małą liczbą rdzeni, CAL+Server może być nadal atrakcyjne (bo płacimy 4× ok. 4k zł za serwer = ~16k, a core 16 rdzeni to może być ~4× wyższa kwota). Gdy jednak VM jest mniej lub obciążenie wymaga większej mocy, licencje core mogą wygrywać elastycznością (i nie wymagają liczenia CAL na użytkownika – co w środowisku z kilkoma VM może się kumulować: w modelu CAL, jeżeli te VM obsługują tych samych użytkowników, nie trzeba dodatkowych CAL, ale jeśli obsługują różne grupy, CAL sumują się).
• Chmura i kontenery: Choć temat dotyczy głównie on-premises, warto wspomnieć: jeśli korzystasz z maszyn w chmurze (Azure, AWS) z własnymi licencjami, również stosujesz powyższe zasady (BYOL – Bring Your Own License). W Azure np. można użyć Azure Hybrid Benefit żeby wykorzystać posiadane licencje, co jest odpowiednikiem licencjonowania core (CSP i subskrypcje to osobny temat). Kontenery (Docker) z SQL Server traktuje się pod względem licencji jak VM – każdy kontener to osobna instancja wymagająca licencji core (przynajmniej 4 core per kontener) chyba że masz SA, wtedy pewne ułatwienia w licencjonowaniu wielu kontenerów na jednym OS wprowadził SQL 2022. To jednak niuans dla bardzo zaawansowanych scenariuszy. Generalnie im bardziej złożona i dynamiczna infrastruktura (klastry, kontenery), tym bardziej preferowany jest model licencjonowania na rdzeń, najlepiej z Software Assurance, żeby mieć pełną swobodę przenoszenia obciążeń.

Liczba rdzeni i wydajność serwera

Parametry samego sprzętu (lub VM), na którym zainstalowany będzie SQL Server, naturalnie wpływają na decyzję licencyjną:

• Moc obliczeniowa serwera: Ile rdzeni ma (lub będzie mieć) serwer, na którym działa SQL? Jeżeli jest to nowoczesna maszyna z 2 procesorami po 16 rdzeni (łącznie 32 rdzenie fizyczne), to licencjonowanie jej w modelu per Core będzie kosztowne – wymaga zakupu 32 licencji (w pakietach 2-rdzeniowych). Czy model CAL będzie tańszy? Zależy od liczby użytkowników: jeżeli np. ten potężny serwer służy tylko 10 użytkownikom, to tak – kupno 10 CAL i 1 licencji serwerowej Standard (zakładając że edycja Standard wystarczy) będzie ułamkiem kosztu 32 core licencji. Jednak uwaga: Edycja Standard i tak nie wykorzysta w pełni 32 rdzeni (limit 24 rdzenie), a jeśli potrzebujemy mocy 32 rdzeni, to pewnie rozważamy Enterprise – a Enterprise nie ma CAL. W praktyce więc dla bardzo dużych serwerów raczej idziemy w licencjonowanie core (bo ma sens przy wielu użytkownikach) albo decydujemy, że tak duży serwer jest nieekonomiczny dla Standard (może lepiej podzielić na VM lub mniejsze serwery, żeby licencje CAL się skalu były sensowniej wykorzystane).
• Minimalne wymagania licencyjne: Wspomnieliśmy już – Microsoft narzuca pewne minima: 4 rdzenie na procesor minimalnie licencjonowane. To oznacza, że bardzo małe serwery (np. jednoprocesorowy z 2 rdzeniami) i tak licencjonujemy jakby miał 4 rdzenie. Model CAL nie ma takich minimów – nawet jak serwer ma 1 rdzeń i 1 użytkownika, kupujemy 1 licencję serwerową + 1 CAL i jesteśmy legalni. W skrajnie małych wdrożeniach to może być argument za CAL. W większości przypadków jednak serwery dziś mają >4 rdzenie, więc minimum nie jest ograniczeniem tylko rzeczywistością.
• Przyszła rozbudowa sprzętu: Jeśli przewidujemy upgrade sprzętu (więcej CPU, migracja na maszynę o większej liczbie rdzeni), to planując model CAL musimy pamiętać, że mocniejszy serwer może obsłużyć więcej użytkowników – a jeśli to nastąpi, znów wrócimy do czynnika liczby użytkowników. Z kolei w modelu Core ewentualna rozbudowa CPU wymaga dokupienia licencji core. Ważne jest, że licencje core są przypisane do fizycznych rdzeni; zmiana hardware często = konieczność aktualizacji licencji. Jeśli firma często zmienia infrastrukturę lub przenosi system między serwerami, model core bez SA może być uciążliwy (bo trzeba przekładać licencje i czekać 90 dni między przepisaniem licencji). W modelu CAL licencja serwerowa Standard też jest przypisana do jednego serwera, ale łatwiej ją „przenieść” – formalnie można przenieść licencję serwerową na inny serwer co 90 dni (podobnie jak core), chyba żeby to była licencja w ramach umowy, wtedy ewentualnie migracja to reinstall i przeniesienie licencji papierowo. W praktyce obydwa modele wymagają śledzenia zmian sprzętu pod kątem licencji.
• Wydajność a koszty: Ciekawym dylematem bywa sytuacja, gdy serwer ma dużo rdzeni, ale niskie użycie (np. jest to nowy serwer przydzielony aplikacji, ale ma zapas mocy). Model core każe płacić za potencjał (wszystkie rdzenie), niezależnie czy są obciążone. Model CAL każe płacić za użytkowników, niezależnie od obciążenia. Jeżeli więc mamy przewymiarowany serwer (duży zapas mocy) i niewielu użytkowników, model CAL pozwala niejako nie płacić za niewykorzystane rdzenie. Oczywiście nie można instalować Standard na części rdzeni – instancja widzi całą maszynę, ale licencja core musiałaby objąć wszystko. Można za to rozważyć wirtualizację: np. utworzyć VM z mniejszą liczbą vCPU na dużym hoście, by ograniczyć licencje core tylko do tych vCPU (i zapewnić, by VM nie rosła powyżej jakiegoś limitu – to trzeba administracyjnie zablokować). Innymi słowy, architektura systemu może być projektowana pod optymalizację licencyjną: jeśli chcę pozostać w modelu CAL, mogę fizycznie rozdzielić systemy na więcej mniejszych instancji zamiast jednej dużej, by nie musieć płacić za mega-serwer licencjami core. To jednak musi być zrównoważone z wydajnością i utrzymaniem.

Konkluzja: analiza mocy serwera i tego, jak będzie wykorzystana, pomaga ocenić koszty licencji. Modele licencyjne niejako mapują koszty na różne „zasoby”: model core wiąże koszt z CPU, a CAL z ludźmi. Trzeba zdecydować, czy koszt CPU czy koszt użytkowników będzie dla nas mniejszy/przystępniejszy przy danej konfiguracji.

Dostęp zewnętrzny vs wewnętrzny

Kwestia typu użytkowników – wewnętrzni czy zewnętrzni – już była poruszana, ale powtórzmy ją jako osobny czynnik, bo jest krytyczna:

• Użytkownicy wewnętrzni (pracownicy, etatowi, uprawnieni kontraktorzy) – mogą być licencjonowani CAL, to dla nich ten model powstał. Jeżeli nasz SQL Server będzie wykorzystywany tylko przez pracowników firmy (np. system HR dostępny tylko dla działu HR, lub baza danych ERP dostępna tylko dla zalogowanych pracowników), to mamy wybór modelu. Możemy albo liczyć ich i kupić CAL, albo pójść w core. Tutaj decydują czynniki finansowe i techniczne wspomniane wyżej (ile ich jest, jaki serwer itp.).
• Użytkownicy zewnętrzni (klienci, partnerzy, obywatele w przypadku instytucji publicznej) – ci nie mogą być objęci tradycyjnymi CAL. Microsoft definiuje licencje CAL jako dostęp tylko dla użytkowników lub urządzeń należących do organizacji licencjobiorcy (lub jego afiliantów). Dla dostępu zewnętrznego kiedyś istniały External Connector – jednorazowa opłata za „mostek” dla nieograniczonej liczby zewnętrznych użytkowników dla jednego serwera. O ile wiem, w przypadku SQL Server od modelu 2012+ raczej się tego nie stosuje – oficjalnym zaleceniem jest licencjonować taki serwer w modelu per Core, co rozwiązuje problem liczenia użytkowników. External Connector częściej był spotykany przy Windows Server/Exchange itp. Zatem jeśli planujesz udostępnić aplikację opartą o SQL Server klientom spoza Twojej firmy lub np. mieszkańcom (dla instytucji publicznej), to praktycznie z automatu wybierasz model core. Nie ma znaczenia, czy tych klientów będzie 50 czy 5000 – i tak nie wolno Ci kupić dla nich CAL. Model core daje spokój: serwer jest licencjonowany i może obsłużyć dowolnych userów.
• Scenariusze mieszane – co jeśli serwer ma służyć zarówno użytkownikom wewnętrznym, jak i zewnętrznym? Np. baza danych ma moduł dla pracowników i portal dla klientów. Tutaj również model core jest jedynym sensownym wyjściem, bo i tak z powodu zewnętrznych musisz licencjonować core, a wtedy nie potrzebujesz CAL dla wewnętrznych (mogą się łączyć bez CAL, bo licencja core to pokrywa). Można by teoretycznie rozdzielić system na dwa serwery: osobny do części zewnętrznej (licencjonowany core) i osobny do wewnętrznej (licencjonowany CAL), ale to dodaje komplikacji i z reguły się nie opłaca, jeśli mowa o jednym systemie – chyba że architektura tak czy siak przewidywała rozdział. W większości przypadków prostsze i często tańsze będzie po prostu licencjonować jeden serwer na rdzenie i mieć pełną swobodę.
• Anonimowy dostęp/publiczny serwis – podobnie jak powyżej, każda publiczna strona, usługa webowa, API itp. korzystające z SQL Server muszą działać na instancji licencjonowanej per Core (bo użytkowników nie da się zidentyfikować, więc CAL odpadają). Nawet jeśli obecnie ruch jest mały (np. 100 odwiedzin dziennie), formalnie i tak potrzebna jest licencja core. Oczywiście, czasem startupy ryzykują działanie na Express albo Developer licząc, że nikt nie zauważy – ale to złamanie licencji i nie radzimy takiego podejścia. Dla ograniczonego ruchu można ewentualnie rozważyć alternatywy jak Azure SQL Database (w chmurze, płatność za zużycie), ale przy on-prem jedyną drogą jest licencja core lub licencja serwerowa + External Connector (jeśli by był dostępny – ale jak wspomniałem, raczej nie jest już dla SQL nowo oferowany).

Podsumowując, typ użytkownika (wewnętrzny vs zewnętrzny) często bywa czynnikiem rozstrzygającym. Dla czysto wewnętrznych systemów mamy opcję CAL, dla jakiegokolwiek zewnętrznego dostępu – praktycznie zostaje core. Warto tę analizę zrobić na etapie planowania systemu: czy na pewno nikt spoza firmy nigdy nie będzie korzystał? Firmy się zmieniają – może dziś system jest tylko wewnętrzny, ale za rok pojawi się pomysł dodania modułu dla klientów. Jeśli wybraliśmy CAL, trzeba będzie dokonać kosztownej zmiany (przejście na core). Dlatego niekiedy lepiej od razu przygotować się na dostęp zewnętrzny i licencjonować rdzenie, jeśli taki scenariusz nie jest wykluczony w przyszłości.

Budżet i plany rozwoju IT

Choć techniczne kwestie są kluczowe, nie można pominąć czynników biznesowych: budżetu przeznaczonego na licencjonowanie oraz ogólnej strategii rozwoju IT w organizacji.

• Budżet jednorazowy vs rozłożony w czasie: Model licencjonowania CAL często wiąże się z niższym kosztem początkowym, zwłaszcza dla małej liczby użytkowników, ale może rosnąć stopniowo (dokupowanie CAL w miarę zatrudniania kolejnych osób lub przyłączenia kolejnych urządzeń). Model core to zazwyczaj wyższy koszt na starcie (musimy kupić licencje na wszystkie rdzenie od razu), ale potem spokój niezależnie od wzrostu liczby userów. Decyzja może więc zależeć od tego, czy firma woli zapłacić więcej od razu za skalowalność (core), czy płacić niżej próg wejścia i dokupować w razie potrzeby (CAL). Należy jednak uważać, by nie patrzeć tylko na tu i teraz – kuszące „kupmy Standard + 5 CAL bo tanio” może zemścić się za rok, gdy trzeba będzie dokupić 50 CAL (co przekroczyło by koszt core, jeśli byśmy od razu kupili). Optymalnie robi się symulację kosztów na 3-5 lat do przodu dla obu modeli.
• Software Assurance (SA): to dodatkowa opcja (zazwyczaj 25% ceny licencji rocznie), która zapewnia prawo do upgrade wersji, pewne dodatkowe prawa (mobilność licencji, pasywny serwer zapasowy, trenowanie pracowników, itp.). SA można dokupić zarówno do licencji core, jak i serwerowych + CAL. Jeśli budżet pozwala i system jest krytyczny, warto rozważyć SA, bo np. nowa wersja SQL wychodzi co ~2-3 lata, a z SA możemy przejść bez kupowania nowych licencji. W kontekście modeli: posiadając SA na licencjach core, mamy większą elastyczność (mobilność wirtualizacji). Posiadając SA na CAL, mamy gwarancję, że CAL-e będą działać z nowszą wersją serwera (przy upgrade SQL nie trzeba kupować nowych CAL). SA to oczywiście dodatkowy koszt, więc planując budżet licencyjny warto uwzględnić: model core + SA vs model CAL + SA vs brak SA – to wszystko różne kombinacje kosztowe i prawne.
• Strategia chmurowa vs on-premises: Coraz więcej organizacji myśli o przenoszeniu części infrastruktury do chmury. Jeśli w planach w horyzoncie licencji (powiedzmy 2-3 lata) jest migracja bazy do Azure SQL lub do maszyny wirtualnej w chmurze, to może warto rozważyć model licencji, który to ułatwi. Licencje core mogą być przeniesione do Azure VM (w ramach Hybrid Benefit) lub do AWS (w ramach tzw. License Mobility jeśli jest SA). Licencje CAL nie mają bezpośredniego przełożenia w chmurze, bo np. w Azure SQL Database płaci się miesięcznie per użytkowanie, niezależnie od CAL. Więc jeśli zakładamy, że w przyszłości porzucimy własny SQL Server na rzecz usługi w chmurze, inwestowanie w drogie licencje core może nie mieć sensu – może wystarczy CAL na okres przejściowy? Albo odwrotnie, jeśli mamy licencje core, możemy je zastosować w modelu IaaS (np. w Azure VM). To są dość zaawansowane rozważania, ale w dużych organizacjach strategia „cloud-first” czy „on-prem for next 5 years” będzie dyktować podejście licencyjne.
• Konsolidacja czy dywersyfikacja: Jeśli planujemy używać SQL Server do wielu celów (np. parę różnych aplikacji) – pytanie brzmi: zainstalować wszystko na jednej instancji czy rozdzielić? Konsolidacja na jednej instancji oznacza jeden model licencyjny dla wszystkiego, za to brak izolacji między aplikacjami i potencjalnie bardziej skomplikowane zarządzanie (oraz większy serwer). Rozdzielenie (np. kilka instancji/VM, każda dla innej aplikacji/działu) daje izolację, ale może podnieść koszty licencji (kilka licencji serwerowych zamiast jednej, etc.). Nieraz firmy decydują się ograniczyć liczbę serwerów SQL z powodów licencyjnych – bo każda nowa instancja Standard w modelu CAL to dodatkowy zakup licencji serwerowej. Alternatywą bywa kupno licencji core na duży serwer i upchanie tam wszystkiego (bo jak już zapłacone za rdzenie, to można wiele baz tam trzymać). Oczywiście trzeba patrzeć na wydajność i ryzyko – awaria jednego serwera dotknie wszystko. Ale to jest element architektury IT, gdzie licencje mają swój wpływ.

Jak widać, czynników jest sporo – liczba userów, wirtualizacja, rdzenie, typ dostępu, budżet, plany przyszłościowe. Dobór modelu licencjonowania SQL Server to zadanie wielowymiarowe. Nie ma uniwersalnej odpowiedzi „zawsze wybierz X”. W mniejszych firmach zazwyczaj wychodzi korzystniej Serwer+CAL, w dużych raczej per Core, ale pośrednie przypadki wymagają analizy. To prowadzi nas do ostatniego ważnego punktu: roli ekspertów w tym procesie.

Dlaczego warto skonsultować wybór z architektem IT?

Mimo że przedstawiliśmy powyżej wiele zasad i wskazówek, świadomy czytelnik z pewnością zauważył, jak złożony jest to temat. Licencjonowanie Microsoft SQL Server (oraz innych produktów Microsoft) podlega wielu regułom, wyjątkowym sytuacjom i zmieniającym się zapisom umów. Wystarczy drobna zmiana założeń projektu, by rekomendacja licencyjna uległa zmianie. Dlatego najlepszą praktyką jest angażowanie doświadczonego architekta IT lub konsultanta ds. licencjonowania przy planowaniu każdego istotnego wdrożenia SQL Server.

Architekt IT lub licencyjny będzie w stanie spojrzeć holistycznie na następujące aspekty:

• Wymagania biznesowe i techniczne – oceni, jakiej edycji SQL Server naprawdę potrzebujesz (Express/Standard/Enterprise), jakie funkcje są kluczowe, jak wysoka dostępność czy skalowalność jest wymagana.
• Infrastrukturę i obciążenia – przeanalizuje Twoje środowisko (fizyczne czy wirtualne, obecne i planowane zasoby sprzętowe, integracje z innymi systemami) i dobierze model licencji pasujący do tej infrastruktury. Np. uwzględni czy masz klaster VMware, czy serwer będzie dedykowany, czy używasz kontenerów itd.
• Aspekty prawne i compliance – ekspert zna aktualne zasady licencjonowania (które potrafią się zmieniać co kilka lat lub mieć inne interpretacje). Doradzi, jak uniknąć ryzyka niezgodności. Może zasugerować zakup Software Assurance gdy widzi, że planujesz rzeczy, które bez SA są ryzykowne (np. częste migracje VM).
• Optymalizację kosztów – doświadczony doradca licencyjny zna różne programy licencjonowania Microsoft (np. licencje grupowe Open Value, oferty dla sektora publicznego, opcje wynajmu SPLA, subskrypcje CSP itp.). Może pomóc dobrać nie tylko model (Core vs CAL), ale i formę zakupu, która będzie najkorzystniejsza finansowo i prawnie dla Twojej instytucji. Czasami np. dla instytucji publicznej opłaca się program licencyjny government, albo dla integratora – umowa partnerska. Softium jako firma specjalizująca się w dostarczaniu legalnego oprogramowania potrafi wskazać te ścieżki.
• Perspektywę rozwoju – architekt zapyta o Twoje plany na przyszłość (co nie zawsze wewnętrznie jest omawiane przy wyborze licencji, bo skupiamy się na „tu i teraz”). Może się okazać, że np. planowana jest centralizacja baz danych z kilku systemów w jeden klaster – lepiej zawczasu pomyśleć o tym licencyjnie. Albo że firma rozważa migrację do chmury – co zmienia podejście (np. może nie warto kupować drogich licencji 3-letnich, tylko iść w subskrypcję roczną?). Taki szerszy ogląd pozwoli uniknąć sytuacji, gdzie za rok trzeba będzie wyrzucić obecne licencje do kosza i kupić nowe, bo obrano złą drogę.

Najważniejsze – nie istnieje prosta tabela czy algorytm, który zawsze powie “Core” albo “CAL”. Każde wdrożenie ma swoją specyfikę. Dlatego staramy się unikać zbytnich uproszczeń (które mogłyby wprowadzić w błąd). Ten artykuł dostarcza wiedzy i kontekstu, ale nie zastąpi konsultacji z ekspertem w Twojej konkretnej sytuacji.

Jeżeli masz wątpliwości co do optymalnego modelu licencjonowania SQL Server w Twojej organizacji, najlepiej skontaktuj się z naszymi specjalistami Softium. Nasi eksperci przeanalizują Twoje potrzeby i przygotują rekomendację szytą na miarę – tak, by spełnić wymagania biznesowe, zapewnić pełen compliance i jednocześnie zoptymalizować koszty. Dzięki temu zyskasz pewność, że Twoja firma jest legalnie i efektywnie wyposażona w niezbędne licencje, a Ty możesz skupić się na rozwijaniu swojego biznesu bez obaw o licencyjne pułapki.

Podsumowanie

Licencjonowanie Microsoft SQL Server w modelu Core vs Server + CAL to zagadnienie wymagające pogłębionej analizy. Model per Core zapewnia prostotę (licencjonowanie mocy serwera i nielimitowany dostęp użytkowników), podczas gdy model Serwer+CAL może być opłacalny w określonych warunkach (mała liczba znanych użytkowników). Kluczowe jest zrozumienie różnic między tymi modelami, aby dobrać wariant najlepiej dopasowany do wielkości i charakteru środowiska. Uniknięcie typowych błędów – takich jak niewłaściwe oszacowanie CAL, pominięcie licencjonowania zapasowych instancji czy błędy w środowiskach wirtualnych – pozwoli uchronić się przed niezgodnością licencyjną. Compliance licencyjne nie jest opcjonalne: brak zgodności może skutkować poważnymi karami finansowymi i zaburzeniami pracy firmy, dlatego zawsze należy dbać o legalność oprogramowania.

Przeanalizowaliśmy także ograniczenia edycji Express i Standard – uświadamiając, że darmowy Express sprawdzi się tylko w najmniejszych rozwiązaniach, a edycja Standard choć potężna, ma limity wydajnościowe i funkcjonalne w porównaniu do Enterprise. Czynniki doboru modelu licencji takie jak liczba użytkowników, wirtualizacja, rdzenie czy dostęp zewnętrzny zostały omówione – wszystkie one wpływają na decyzję Core vs CAL. Ostatecznie, podkreśliliśmy znaczenie eksperckiego doradztwa – dobór licencji powinien być przeprowadzony przez kompetentnego architekta IT, ponieważ niewłaściwe decyzje mogą kosztować krocie lub narazić firmę na ryzyko.

Mamy nadzieję, że ten obszerny przewodnik pomógł Ci zrozumieć niuanse licencjonowania SQL Server i przybliżył Cię do podjęcia właściwej decyzji. Jeśli potrzebujesz indywidualnej konsultacji lub masz dodatkowe pytania, skontaktuj się z ekspertami Softium – chętnie pomożemy w doborze najlepszego modelu licencjonowania dla Twojej organizacji. Pamiętaj, że inwestycja w właściwe licencje to inwestycja w bezpieczeństwo i stabilność działania Twojego biznesu.

Skontaktuj się z nami – nasi doradcy czekają, aby zapewnić Ci profesjonalne wsparcie w zakresie licencjonowania Microsoft SQL Server i nie tylko. Zapraszamy do współpracy!