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.

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.

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.