Historyczne zmagania z #SQLServer

Końcówka roku 2016. Kilka miesięcy po premierze SQL Server 2016. Czas rozwiązań in-memory, indeksów kolumnowych i zaawansowanej analityki, tymczasem w wielu miejscach czas jakby się zatrzymał. Wiele rozwiązań wciąż korzysta z SQL Server 2005, który nie jest już objęty jakimkolwiek wsparciem, co oznacza brak poprawek bezpieczeństwa, brak aktualizacji oraz potencjalnej możliwości uzyskania wsparcia, nawet przy błędach krytycznych w działaniu systemu. W przypadku tego typu rozwiązań zawsze staram się zrozumieć co leży u podstaw decyzji, a raczej jej braku w kwestii podniesienia wersji, co najmniej o jedną lub kilka wersji wyżej.

W wielu przypadkach decyzja o utrzymaniu wersji jest częściowo uzasadniona przez planowane wyłączenie systemu, które miało nastąpić, ale z różnych przyczyn przeciągnęło się w czasie. Takie utrzymanie wersji powiązane z planowanym wyłączeniem faktycznie skutecznie powstrzymuje od aktualizacji, zwłaszcza jeśli system nie jest rozwijany, a jedynie utrzymywany. Co więcej raczej trudno wynegocjować środki na aktualizację takie systemu. Decyzja oczywiście niesie ze sobą ryzyko, jednak ryzyko,którego koszt jest relatywnie niższy, niż projekt aktualizacji. (Jestem w stanie takie uzasadnienie zrozumieć :))

Są również przypadki, w których system działający w oparciu o SQL Server 2005 co prawda nie jest już rozwijany, jest jednak nadal kluczowym systemem w danej organizacji i nie jest planowane jego wyłączenie w najbliższym czasie. Co więcej w związku z planowanym zmianami pojawiają się pomysły zmierzające np. do wirtualizacji działającego do tej pory serwera SQL. Rzecz jasna wirtualizacja ma ograniczyć koszt, skoro planujemy ograniczenie kosztów to zakup nowych licencji raczej nie jest uzasadniony. W tym miejscu warto zadać sobie pytanie, czy posiadane licencje po zmianie architektury z fizycznej na wirtualną, nadal mogą być wykorzystywane tak, aby nie narażać się na wystąpienie niezgodności licencyjnej. Dla przykładu,obecna konfiguracja środowiska to jeden serwer fizyczny, wyposażony w 2 procesory(każdy procesor posiada 1 rdzeń). Na serwerze zainstalowany jest SQL Server 2005 Standard Edition, licencjonowany w modelu na procesor. Nowa architektura zakłada wirtualizację serwera. Przygotowana maszyna wirtualna dysponować będzie dwoma procesorami wirtualnymi(dla zachowania zgodności z obecną konfiguracją), jednak środowiskiem uruchomienia  maszyny wirtualnej będzie host fizyczny, wyposażony w 4 procesory, każdy procesor posiada 8 rdzeni, dodatkowo dla serwera włączono Hyper Treading. Czy w takiej sytuacji można wykorzystać posiadane 2 licencje na procesor dla SQL Server 2005 Standard Edition czy też może konieczne jest licencjonowanie wszystkich procesorów/rdzeni serwera fizycznego, na którym uruchomiona zostanie maszyna wirtualna?

Odpowiedź nie jest prosta, zwłaszcza, że od momentu zakupu licencji na SQL Server 2005 Standard Edition 2 CPU, do teraz minęło trochę czasu, a w tym czasie zaszły spore zmiany w zapisach licencyjnych dla SQL Server oraz samym modelu licencjonowania. Co zatem zrobić? Jak zyskać pewność?

  1. Na początek warto sprawdzić, czy zakupiona licencja zakupiona była z pakietem Software Assurance. Ktoś zapyta dlaczego to takie ważne?  W przypadku jeśli licencja na SQL Server 2005 Standard Edition zakupiona została z aktywnym pakietem Software Assurance i w trakcie trwania SA pojawiła się nowa wersja SQL Server, automatycznie zakupiona licencja została podniesiona do nowej wersji, czyli SQL Server 2008 Standard Edition. Wraz z prawem do nowej wersji pojawiła się również konieczność zastosowania zapisów licencyjnych nowej wersji, a nie zapisów dla uprzednio zakupionej licencji.
  2. Po weryfikacji, dla której wersji oprogramowania poszukiwane są zapisy licencyjne należy odszukać odpowiedni dokument licencyjny. Lata 2005-2015 to okres obowiązywania Product Use Rights dla licencji zakupionych w umowach grupowych. Szczęśliwie w prosty sposób można dotrzeć do archiwalnych dokumentów PUR
  3. Po odnalezieniu odpowiedniego dokumentu PUR należy sprawdzić zapisy dot. możliwości uruchomienia SQL Server 2005 Standard w środowisku wirtualnym:

(…) Każdy procesor, z którego oprogramowanie korzysta, musi być objęty właściwą licencją. (..). W przypadku oprogramowania uruchamianego w wirtualnych środowiskach systemu operacyjnego konieczne jest tylko uzyskanie licencji na wirtualne procesory, z których to oprogramowanie korzysta.

Źródło: Prawa do używania produktów licencjonowanych przez firmę Microsoft, Kwiecień 2008

Informacja bardzo cenna, bo wiadomo już, że można skorzystać z licencjonowania tylko procesorów faktycznie wykorzystywanych przez SQL Server. Należy również sprawdzić zapisy szczegółowe dla produktu, w tym przypadku pojawia się dodatkowa informacja

(…) dla każdego procesora wirtualnego używanego w każdym z tych wirtualnych środowisk systemu operacyjnego potrzebna jest licencja na oprogramowanie. Jeśli w wirtualnym środowisku systemu operacyjnego używa się części procesora wirtualnego, część ta jest traktowana jako pełny procesor wirtualny.

Źródło: Prawa do używania produktów licencjonowanych przez firmę Microsoft, Kwiecień 2008

Całość dopełnia zawarty w PUR przykład dot. SQL Server Standard

pur_sql

Źródło: Prawa do używania produktów licencjonowanych przez firmę Microsoft, Kwiecień 2008

Na koniec warto potwierdzić czy licencja może być przenoszona pomiędzy serwerami, aby uzyskać pewność, że posiadaną licencję można przenieść na nowe środowisko:

(…) Można zmieniać przypisanie licencji na oprogramowanie, ale nie krótkoterminowo (tj. nie wcześniej niż po upływie 90 dni od ostatniej zmiany przypisania). Zmiany przypisania można dokonać wcześniej, jeśli wskutek trwałej awarii sprzętu licencjonowany serwer przestanie być używany. W przypadku zmiany przypisania licencji na inny serwer „licencjonowanym serwerem” w ramach tej licencji staje się ten serwer, do którego zostanie przypisana licencja.

Źródło: Prawa do używania produktów licencjonowanych przez firmę Microsoft, Kwiecień 2008