Licencja na bazę danych: jak liczy się koszt SQL Server i Oracle w firmie

Licencji na bazę danych nie liczy się od liczby instalacji, tylko od mocy obliczeniowej albo od liczby użytkowników. SQL Server rozlicza się w modelu per rdzeń procesora albo w modelu serwer plus licencje dostępowe CAL, a Oracle w modelu per procesor albo per użytkownik nazwany, z ustalonym minimum. Wirtualizacja potrafi zwielokrotnić liczbę wymaganych licencji.

To jest kategoria, w której polskie firmy przepłacają najczęściej i dowiadują się o tym najpóźniej. Baza danych nie ma widocznego interfejsu, którym ktoś by się przejmował, stoi na serwerze od lat i nikt jej nie rusza, dopóki nie przyjdzie audyt albo migracja. Wtedy okazuje się, że model licencjonowania miał niewiele wspólnego z tym, co firma faktycznie kupiła.

Jak liczy się licencja na bazę danych

Producenci baz danych wyszli z założenia, że wartość, jaką klient czerpie z produktu, jest proporcjonalna do mocy obliczeniowej, na której baza pracuje, albo do liczby osób i urządzeń, które z niej korzystają. Stąd dwa dominujące modele, a nie licencja na instalację, do której przyzwyczaiło firmy oprogramowanie biurowe.

Model pierwszy to licencjonowanie od zasobów: liczysz rdzenie fizyczne albo procesory serwera, na którym działa silnik bazy, i licencjonujesz je wszystkie, niezależnie od tego, ilu ludzi korzysta z systemu. Model drugi to licencjonowanie od dostępu: licencjonujesz sam serwer, a do tego dokupujesz uprawnienie dla każdego użytkownika albo urządzenia, które łączy się z bazą.

Wybór między nimi nie jest kwestią gustu, tylko rachunku. Baza obsługująca sklep internetowy z nieprzewidywalną liczbą klientów praktycznie zawsze idzie w model rdzeniowy, bo liczby użytkowników nie da się policzyć. Baza wewnętrznego systemu ERP z trzydziestoma pracownikami zwykle wychodzi taniej w modelu serwer plus CAL.

SQL Server: per rdzeń czy serwer plus CAL

Microsoft oferuje oba modele, ale nie dla wszystkich edycji. Edycja Enterprise jest dostępna wyłącznie w modelu rdzeniowym, edycja Standard w obu. To pierwsza rzecz do sprawdzenia, bo zmiana edycji potrafi zmienić cały rachunek bardziej niż negocjacja rabatu.

W modelu rdzeniowym licencjonuje się wszystkie rdzenie fizyczne serwera, z określonym minimum na każdy procesor. Nie liczy się rdzeni, na których baza faktycznie pracuje, tylko te dostępne w maszynie. Serwer z dwoma procesorami po osiem rdzeni to szesnaście rdzeni do zalicencjonowania, nawet jeśli baza obsługuje jedną aplikację i dwadzieścia osób.

W modelu serwer plus CAL kupujesz licencję na instancję serwera i osobno licencje dostępowe. Tu z kolei kryje się najczęstszy błąd inwentaryzacyjny: CAL trzeba mieć dla każdego użytkownika albo urządzenia korzystającego z bazy, także pośrednio. Pracownik, który nigdy nie widział bazy na oczy, ale korzysta z aplikacji, która z niej czyta, również wymaga uprawnienia. Ta zasada dotyczy zresztą także innych produktów serwerowych i opisujemy ją przy licencjach Windows Server, a szczegóły edycji przy licencjach SQL Server.

Dlaczego wirtualizacja zwiększa liczbę wymaganych licencji

To jest miejsce, w którym najwięcej firm dostaje po audycie rachunek, którego się nie spodziewało. Zasada wygląda niewinnie: jeśli baza pracuje na maszynie wirtualnej, licencjonujesz rdzenie przypisane do tej maszyny, ale z określonym minimum. Problem zaczyna się wtedy, gdy klaster wirtualizacyjny pozwala maszynie przenieść się na dowolny host.

W wielu scenariuszach mobilność maszyny wirtualnej w klastrze oznacza konieczność zalicencjonowania wszystkich hostów, na które ta maszyna mogłaby się przenieść, a nie tylko tego, na którym akurat stoi. Firma, która zbudowała klaster z sześciu serwerów dla bezpieczeństwa, może więc nieświadomie potroić zobowiązanie licencyjne, robiąc coś, co z punktu widzenia inżynierii jest oczywiście słuszne.

Dlatego decyzje architektoniczne w środowisku wirtualnym powinny być konsultowane z osobą, która rozumie warunki licencyjne, a nie tylko z zespołem infrastruktury. Tam, gdzie to możliwe, warto rozważyć wydzielenie hostów przeznaczonych wyłącznie pod bazy danych i wyłączenie ich z ogólnej puli. To samo dotyczy platformy wirtualizacyjnej, której własny model licencjonowania zmienił się po przejęciu VMware przez Broadcom, o czym piszemy przy licencjach VMware. Jeżeli po tej zmianie rozważacie zejście z vSphere, warianty razem z cenami producentów zestawiamy na stronie o alternatywach dla VMware: przy bazach danych wybór hypervisora przekłada się wprost na liczbę rdzeni do zalicencjonowania.

Oracle: dlaczego rachunek bywa nieprzewidywalny

Oracle stosuje dwa podstawowe modele: per procesor i per użytkownik nazwany. W modelu procesorowym liczba licencji zależy nie od samej liczby procesorów, ale od iloczynu rdzeni i współczynnika przypisanego do architektury procesora, co oznacza, że dwa serwery o podobnej wydajności mogą wymagać różnej liczby licencji.

W modelu użytkowników nazwanych obowiązuje minimum na procesor, więc nawet mała instalacja ma podłogę kosztową, poniżej której nie zejdzie. Do tego dochodzą opcje i pakiety zarządzania, które bywają domyślnie dostępne w instalacji, a licencjonowane osobno. Włączenie funkcji, o której nikt nie pomyślał jak o osobnym produkcie, potrafi wygenerować zobowiązanie znacznie większe niż sama baza.

Praktyczny wniosek jest jeden i niewygodny: przy Oracle nie da się wyliczyć kosztu bez zajrzenia do konkretnej umowy i do konfiguracji środowiska. Ogólne cenniki służą do wstępnego oszacowania, a nie do budżetowania. Co da się kupić w wersji wieczystej i na jakich zasadach, opisujemy przy licencjach Oracle.

Gdzie firmy najczęściej przepłacają za bazy danych

Powtarzalne przyczyny są cztery i każda z nich jest do usunięcia bez zmiany technologii.

• Edycja większa niż potrzeby. Enterprise kupione dla funkcji, których nikt nie włączył, przy zapotrzebowaniu, które obsłuży Standard.
• Środowiska testowe licencjonowane jak produkcyjne. Producenci przewidują dla nich osobne, tańsze warunki, z których firmy nie korzystają, bo nikt nie sprawdził.
• Nieużywane instancje. Baza po projekcie, który skończył się dwa lata temu, nadal działa i nadal generuje zobowiązanie licencyjne.
• Zbyt szeroki klaster wirtualizacyjny. Mobilność maszyny wirtualnej rozciąga zobowiązanie na hosty, na których baza nigdy nie stanęła.

Wszystkie cztery wychodzą przy jednym ćwiczeniu: zestawieniu tego, co jest zainstalowane i uruchomione, z tym, co firma kupiła. Dokładnie na tym polega audyt licencji oprogramowania, a punktem wyjścia jest inwentaryzacja oprogramowania. W środowiskach bazodanowych ten rachunek zwykle wypada w obie strony: coś jest zalicencjonowane za słabo, a coś innego zdecydowanie za mocno.

Licencjonowanie starych wersji: SQL Server 2012 i nowsze

Sporo polskich firm nadal utrzymuje bazy na wersjach, których Microsoft już nie wspiera, i to właśnie tam licencyjny bałagan bywa największy. Warto znać jedną zmianę z tamtych lat, bo wciąż rzutuje na wyceny: to SQL Server 2012 zastąpił licencjonowanie na procesory modelem rdzeniowym, który obowiązuje do dziś. Licencje rdzeniowe sprzedawano w pakietach po dwa rdzenie, z minimum czterech licencji na każdy procesor fizyczny, więc serwer z dwoma dwurdzeniowymi procesorami i tak wymagał ośmiu licencji.

Druga zmiana z tej samej wersji zaskakuje przy audytach do dziś. W SQL Server 2012 edycja Enterprise przestała być dostępna w modelu serwer plus CAL dla nowych zakupów, więc firma, która pamięta ten model z wersji 2008 R2, nie odtworzy go w nowszym środowisku. Licencje wieczyste kupione wtedy pozostają ważne bezterminowo i podlegają odsprzedaży, ale nie da się na nich zbudować rozbudowy na nowym sprzęcie bez przejścia na model rdzeniowy.

Do tego dochodzą daty, po których baza działa dalej, ale nie dostaje już poprawek bezpieczeństwa. Wsparcie SQL Server 2012 skończyło się 12 lipca 2022, SQL Server 2014 dziewiątego lipca 2024, a SQL Server 2016 czternastego lipca 2026, czyli miesiąc temu. Dla systemu, do którego sięgają dane osobowe albo klienci z zewnątrz, to jest termin do potraktowania poważnie, bo od tego dnia każda nowa podatność zostaje niezałatana na stałe.

Praktyczna wskazówka przy wymianie starej bazy: policz najpierw licencje dostępowe, a dopiero potem serwer. CAL musi być w wersji serwera albo nowszej, więc podnosząc bazę z rocznika 2012 na 2022 wymieniasz także komplet uprawnień użytkowników. Przy kilkudziesięciu osobach to zwykle większa pozycja niż sama licencja silnika. Aktualne ceny obu składników zebraliśmy przy licencjach SQL Server.

Co zrobić z licencjami po migracji albo konsolidacji

Konsolidacja serwerów i przejście części systemów do chmury zostawia firmy z wieczystymi licencjami bazodanowymi, których nie mają już gdzie użyć. To są jedne z najdroższych pozycji w całym rejestrze oprogramowania, więc pozostawienie ich bezczynnie w ewidencji jest kosztowną bezczynnością.

Wieczyste licencje SQL Server podlegają obrotowi wtórnemu na tych samych zasadach co reszta oprogramowania wieczystego, czyli na podstawie wyczerpania prawa do dystrybucji z wyroku TSUE C-128/11. Warunkiem jest komplet dokumentacji i trwałe zaprzestanie używania. Ile realnie można za nie dostać, tłumaczymy przy wycenie oprogramowania, a sam proces przy sprzedaży licencji.

W drugą stronę działa to tak samo. Firma, która potrzebuje wieczystej licencji serwerowej i nie chce wchodzić w model subskrypcyjny, znajdzie ją taniej na rynku wtórnym niż w kanale pierwotnym, z jawną ceną i pełnym łańcuchem własności widocznym przed zakupem. Przy okazji warto sprawdzić, gdzie fizycznie stoi serwer z bazą, bo przy danych osobowych i przy wymaganiach umownych klientów serwery utrzymywane w Polsce upraszczają rozmowę o zgodności bardziej niż jakikolwiek załącznik do umowy.