Microsoft Azure i środowiska hybrydowe. Kiedy aplikacja w chmurze wymaga licencji CAL dla lokalnej infrastruktury?

Wprowadzenie

Migracja aplikacji do chmury jest jednym z najczęściej realizowanych projektów infrastrukturalnych w organizacjach. Coraz więcej przedsiębiorstw decyduje się na uruchamianie aplikacji biznesowych w Microsoft Azure, pozostawiając jednocześnie część zasobów w lokalnym centrum danych. Takie podejście pozwala szybciej wykorzystać możliwości chmury bez konieczności przeprowadzania pełnej migracji wszystkich systemów.

W praktyce wiele środowisk funkcjonuje obecnie w modelu hybrydowym. Serwery aplikacyjne działają w Azure, natomiast bazy danych, usługi integracyjne lub systemy wspierające nadal pozostają w infrastrukturze lokalnej. Choć taka architektura jest powszechnie stosowana, bardzo często prowadzi do błędnych interpretacji zasad licencjonowania, szczególnie w obszarze Windows Server CAL oraz SQL Server CAL.

Jednym z najczęściej spotykanych błędów jest przekonanie, że przeniesienie aplikacji do Microsoft Azure automatycznie eliminuje konieczność analizowania wymagań licencyjnych związanych z lokalnymi serwerami. W rzeczywistości o obowiązkach licencyjnych decyduje nie lokalizacja aplikacji, lecz zasoby infrastruktury, z których korzysta użytkownik końcowy.

Windows Server w Microsoft Azure bez licencji CAL

Standardowe maszyny wirtualne Windows Server uruchamiane w Microsoft Azure nie wymagają licencji Windows Server CAL dla użytkowników lub urządzeń uzyskujących do nich dostęp. Uprawnienia dostępu do systemu operacyjnego są uwzględnione w opłacie za usługę Azure i stanowią element modelu subskrypcyjnego.

Dla organizacji oznacza to uproszczenie zarządzania licencjami. Nie ma konieczności przypisywania licencji CAL użytkownikom korzystającym wyłącznie z usług działających w Azure. Nie ma również potrzeby ewidencjonowania dostępu do serwerów Windows Server funkcjonujących wyłącznie w środowisku chmurowym.

To właśnie ten model powoduje, że wiele organizacji zakłada, iż po migracji aplikacji do Azure temat licencji dostępowych przestaje istnieć. Jest to jednak prawdą wyłącznie w sytuacji, gdy wszystkie elementy rozwiązania działają w środowisku chmurowym.

Środowisko hybrydowe zmienia zasady gry

Problemy pojawiają się najczęściej wtedy, gdy aplikacja działa w Microsoft Azure, natomiast dane nadal przechowywane są w lokalnym centrum danych.

Typowym przykładem jest aplikacja biznesowa uruchomiona na maszynie wirtualnej Azure, która komunikuje się z bazą danych SQL Server działającą lokalnie na platformie VMware lub Microsoft Hyper-V. Dla użytkownika aplikacja znajduje się w chmurze, jednak dane pobierane są z infrastruktury on-premises.

W takiej sytuacji użytkownik faktycznie korzysta nie tylko z zasobów Azure, ale również z usług dostarczanych przez lokalne serwery. Oznacza to, że analiza wymagań licencyjnych nie może ograniczać się wyłącznie do środowiska chmurowego.

Podczas audytów licencyjnych często spotykane są sytuacje, w których organizacja prawidłowo rozlicza wykorzystanie usług Azure, jednocześnie pomijając wymagania licencyjne wynikające z korzystania z lokalnej infrastruktury.

Aplikacja w Azure, baza danych lokalnie

Rozważmy jeden z najczęściej spotykanych scenariuszy.

Aplikacja biznesowa została wdrożona na maszynie wirtualnej w Microsoft Azure. Użytkownicy logują się do niej przez przeglądarkę internetową i wykonują codzienne operacje biznesowe. Wszystko wskazuje na to, że system działa w chmurze.

Jednak baza danych SQL Server nadal znajduje się w lokalnym centrum danych organizacji. SQL Server jest uruchomiony na maszynie wirtualnej VMware lub Hyper-V działającej pod kontrolą systemu Windows Server.

W takim przypadku każde odczytanie danych, zapis rekordu lub wygenerowanie raportu wiąże się z wykorzystaniem lokalnej infrastruktury. Mimo że użytkownik nie ma świadomości istnienia lokalnego serwera, nadal korzysta z jego usług.

Z perspektywy licencjonowania ma to kluczowe znaczenie.

Dostęp do lokalnego Windows Server

Jeżeli aplikacja działająca w Azure wykorzystuje zasoby lokalnego serwera Windows Server, należy przeanalizować wymagania dotyczące licencji dostępowych.

Wiele organizacji błędnie zakłada, że użytkownik korzysta wyłącznie z usługi chmurowej, ponieważ nie loguje się bezpośrednio do lokalnego serwera. Tymczasem podczas audytu analizowana jest rzeczywista ścieżka dostępu do zasobów.

Jeżeli lokalny Windows Server realizuje funkcje niezbędne do działania aplikacji, użytkownicy korzystający z tej aplikacji mogą podlegać wymaganiom licencyjnym dotyczącym środowiska lokalnego.

To właśnie ten aspekt bardzo często jest pomijany podczas migracji aplikacji do Azure.

SQL Server w modelu Server + CAL

Jeszcze większe znaczenie ma analiza środowiska SQL Server.

Jeżeli lokalna baza danych została licencjonowana w modelu Server + CAL, organizacja musi posiadać nie tylko licencję serwerową SQL Server, ale również odpowiednie licencje SQL Server CAL dla użytkowników lub urządzeń uzyskujących dostęp do danych.

Bardzo często przyjmuje się błędne założenie, że skoro użytkownik nie łączy się bezpośrednio z bazą danych, licencje SQL Server CAL nie są wymagane.

W praktyce jest dokładnie odwrotnie. Jeżeli aplikacja uruchomiona w Azure korzysta z lokalnego SQL Server, użytkownicy tej aplikacji korzystają również z usług SQL Server. Sam sposób realizacji połączenia nie eliminuje obowiązków licencyjnych.

Multiplexing nie zmniejsza liczby wymaganych licencji

Opisany scenariusz jest klasycznym przykładem działania mechanizmów multiplexingu.

Multiplexing występuje wtedy, gdy pomiędzy użytkownikiem a serwerem działa warstwa pośrednicząca ograniczająca liczbę bezpośrednich połączeń z serwerem. Może to być aplikacja biznesowa, portal internetowy, system ERP, API lub inne rozwiązanie integracyjne.

W omawianym przypadku lokalny SQL Server może widzieć wyłącznie jedno konto techniczne wykorzystywane przez aplikację działającą w Azure. Nie oznacza to jednak, że wystarczy jedna licencja SQL Server CAL.

Wymagana liczba licencji zależy od liczby użytkowników lub urządzeń korzystających z danych przechowywanych w SQL Server, a nie od liczby połączeń widocznych na serwerze.

To jeden z najczęściej identyfikowanych problemów podczas audytów środowisk hybrydowych.

A co w przypadku serwera Linux w Azure?

Kolejnym błędnym założeniem jest przekonanie, że obowiązki licencyjne wynikają wyłącznie z wykorzystania technologii Microsoft.

Rozważmy sytuację, w której aplikacja działa na maszynie wirtualnej Microsoft Azure z systemem Linux. Wielu administratorów zakłada wtedy, że temat licencji Windows Server CAL lub SQL Server CAL przestaje istnieć, ponieważ aplikacja nie korzysta z systemu Windows Server.

W rzeczywistości system operacyjny serwera aplikacyjnego nie ma tutaj decydującego znaczenia.

Jeżeli aplikacja uruchomiona w systemie Linux w Azure komunikuje się z lokalnym SQL Server lub wykorzystuje usługi realizowane przez lokalne serwery Windows Server, użytkownicy nadal uzyskują dostęp do zasobów znajdujących się w infrastrukturze on-premises.

Z perspektywy licencjonowania analizowany jest rzeczywisty dostęp do danych i usług, a nie technologia wykorzystana do uruchomienia aplikacji. Oznacza to, że nawet aplikacja działająca w systemie Linux może powodować konieczność posiadania licencji Windows Server CAL oraz SQL Server CAL dla użytkowników korzystających z lokalnej infrastruktury.

Jest to obszar, który bardzo często umyka zarówno administratorom systemów, jak i zespołom odpowiedzialnym za migrację do chmury.

Kiedy licencje SQL Server CAL nie są wymagane??

Sytuacja wygląda inaczej, gdy lokalna baza danych SQL Server została licencjonowana w modelu Per Core.

W takim modelu organizacja licencjonuje rdzenie procesorów przypisane do serwera lub maszyny wirtualnej. Dostęp użytkowników nie wymaga wówczas licencji SQL Server CAL.

Oznacza to, że użytkownicy aplikacji działającej w Azure mogą korzystać z danych przechowywanych w lokalnym SQL Server bez konieczności posiadania licencji SQL Server CAL, pod warunkiem, że środowisko zostało prawidłowo licencjonowane w modelu Per Core.

Nie eliminuje to jednak konieczności przeanalizowania wymagań związanych z dostępem do innych usług działających w środowisku lokalnym.

Najczęstsze błędy wykrywane podczas audytów

Audyty licencyjne środowisk hybrydowych najczęściej wykazują niezgodności w następujących obszarach:

• błędne założenie, że użytkownicy aplikacji działającej w Azure nie wymagają dostępu licencyjnego do lokalnych serwerów,
• nieuwzględnianie użytkowników korzystających z lokalnego SQL Server za pośrednictwem aplikacji uruchomionych w chmurze,
• nieprawidłowa interpretacja zasad multiplexingu,
• brak wymaganych licencji SQL Server CAL dla użytkowników korzystających z lokalnych baz danych,
• błędna ocena wpływu środowisk Linux działających w Azure na wymagania licencyjne infrastruktury lokalnej,
• niepełna dokumentacja przepływu danych pomiędzy środowiskiem Azure a infrastrukturą on-premises,
• pomijanie wymagań licencyjnych podczas częściowych migracji do chmury.

Podsumowanie

Microsoft Azure znacząco upraszcza licencjonowanie dostępu do serwerów uruchamianych w chmurze. Nie oznacza to jednak, że migracja aplikacji do Azure automatycznie eliminuje wymagania licencyjne związane z lokalnym centrum danych.

Jeżeli aplikacja działająca w Azure korzysta z lokalnego Windows Server lub lokalnej bazy SQL Server, organizacja powinna przeanalizować wymagania dotyczące licencji dostępowych. Dotyczy to zarówno środowisk opartych na Windows Server, jak i rozwiązań wykorzystujących serwery Linux uruchomione w chmurze.

Kluczowe znaczenie ma zawsze odpowiedź na jedno pytanie: czy użytkownik korzysta z zasobów znajdujących się w lokalnej infrastrukturze? Jeżeli odpowiedź brzmi "tak", sama obecność aplikacji w Microsoft Azure nie oznacza automatycznego zwolnienia z obowiązków licencyjnych dotyczących środowiska on-premises.

Masz środowisko hybrydowe Azure + on-premises? Sprawdź, czy licencjonowanie jest prawidłowe.

Migracja aplikacji do Microsoft Azure nie zawsze oznacza wyeliminowanie obowiązków licencyjnych związanych z infrastrukturą lokalną. Połączenie Azure z lokalnymi serwerami Windows Server, SQL Server lub innymi usługami może wymagać ponownej analizy zasad licencjonowania.

RESPONSE pomoże ocenić, jak architektura Twojego środowiska wpływa na wymagania licencyjne, zidentyfikować potencjalne ryzyka oraz zweryfikować prawidłowość zastosowanych modeli licencyjnych.

Skonsultuj swoje środowisko hybrydowe z ekspertami RESPONSE.