Punkt decyzyjny: VDI i Terminal Services

O palmę pierwszeństwa — jeśli technologie w ogóle dbają o pierwszeństwo — w dziedzinie zdalnych graficznych interfejsów desktopowych rywalizują dwie podstawowe koncepcje: VDI (wirtualna infrastruktura desktopowa) i terminal services. Idea obu jest prosta: umieścić zasoby i przetwarzanie na serwerze i umożliwić użytkownikom końcowym zdalny dostęp do interfejsu graficznego przez sieć. To, co fundamentalnie odróżnia VDI od TS, to różnica między tym, że zdalny serwer jest środowiskiem jeden-do-wielu, gdzie wielu użytkowników korzysta z desktopów z jednego obrazu systemu operacyjnego (TS), a tym, że każdy użytkownik otrzymuje dedykowany własny serwer (zakładamy wirtualizowany, zwany VDI), gdzie nie ma współdzielenia zasobów indywidualnego systemu operacyjnego.

Istnieje pewne założenie, częściowo wynikające z konwencji nazewnictwa, że VDI implikuje desktopowy system operacyjny, a nie serwerowy, ale nie należy tego traktować jako implikacji. W rzeczywistości poza światem Windows nie ma prawdziwego rozdzielenia między desktopowymi i serwerowymi systemami operacyjnymi, więc takie rozróżnienie na poziomie technologicznym nie miałoby sensu. Ważne jest jednak, aby pamiętać, że Microsoft definiuje licencjonowanie VDI przez użycie różnych opcji licencji OS i większość VDI dotyczy systemów operacyjnych Windows, więc choć VDI tego nie implikuje, to w praktyce warto mieć na uwadze, że po stronie technicznej nie ma rozróżnienia, a po stronie licencjonowania Microsoft istnieją poważne rozróżnienia.

Z tych dwóch rozwiązań VDI jest nowszą koncepcją. Terminal Services istnieją od dziesięcioleci i są dobrze znane — daleko im dziś do czegoś ekscytującego lub efektownego. Terminal services wyprzedzają Windows i są powszechne dla niemal każdej rodziny systemów operacyjnych; w środowisku UNIX są tak powszechne, że często są używane bez zbędnej wzmianki. Terminal services stanowią grafyczną kontynuację starych terminali “zielonego ekranu”, używanych od “zamierzchłych czasów” komputerów. W starych dobrych czasach terminale były często podłączonymi szeregowo terminalami VT100, a dziś używamy sieci TCP/IP i protokołów zdolnych do przenoszenia grafiki, ale koncepcja pozostaje ta sama: wielu użytkowników na jednym serwerze.

W przypadku VDI osiągamy te same cele, ale robimy to, dając każdemu użytkownikowi wszystkie własne zasoby. Ich system operacyjny jest całkowicie ich własny, nieudostępniany nikomu innemu. Oznacza to, że dla każdego indywidualnego użytkownika istnieje cały narzut związany z zarządzaniem pamięcią, zarządzaniem CPU, tabelami procesów, kopiami bibliotek i tym podobnymi. To spory narzut. Wystarczy pomyśleć o zasobach, których wymaga bezczynny graficzny desktop tylko po to, żeby się uruchomić i czekać na użytkownika — może to być całkiem sporo. Nowsze systemy operacyjne Windows stają się coraz szczuplejsze i bardziej wydajne, prawdopodobnie po to, by stały się bardziej życiowe na infrastrukturach VDI, ale narzut pozostaje istotnym czynnikiem. VDI naprawdę nie było możliwe, dopóki wirtualizacja nie uczyniła go rzeczywistością, więc w każdym praktycznym sensie jest to nowe zastosowanie technologii i jest często źle rozumiany.

Stoimy teraz przed wyborem, decydując o zdalnej infrastrukturze obliczeniowej, między tymi dwiema koncepcjami architektonicznymi. Należy oczywiście zauważyć, że te dwa rozwiązania mogą bardzo łatwo współistnieć i często byłoby właściwe, aby tak było. W mniejszych firmach oba rozwiązania mogłyby łatwo współistnieć na tej samej fizycznej platformie. Istnieje wiele czynników, które należy wziąć pod uwagę, a ten proces decyzyjny może być naprawdę dość skomplikowany.

Jednym z największych czynników, który musimy wziąć pod uwagę, jest kompatybilność oprogramowania. Jest to największy czynnik napędzający przejście na VDI zamiast terminal services. W świecie Windows nierzadko zdarza się, że aplikacje wymagają takich rzeczy jak sygnatura desktopowego systemu operacyjnego (odmawiają uruchomienia na wariantach serwerowego OS), środowisk jednoużytkownikowych, przywilejów administratora, uruchamiania pod konkretnymi kontami lub wymagań bibliotecznych, które często kolidują z innymi pakietami. Ze względu na te problemy wiele firm sięga po VDI, aby naśladować sposób działania indywidualnych desktopów, gdzie problemy te były łatwo pomijane, ponieważ każdy użytkownik działał w odrębnym środowisku. VDI przenosi tę samą funkcjonalność do świata zdalnego dostępu, umożliwiając obsługę problematycznych aplikacji w razie potrzeby. Izolacja systemu operacyjnego dodaje dodatkową warstwę ochrony.

Ten czynnik napędowy praktycznie nie istnieje poza światem Windows i jest głównym powodem, dla którego VDI nigdy nie przyjęło się w żadnym innym środowisku. Choć łatwo osiągalne przy użyciu np. Linux lub FreeBSD, VDI ma małe zastosowanie lub wartość w tych przypadkach.

Głównym problemem związanym z VDI jest ogromny narzut niezbędny do zarządzania wieloma redundantnymi systemami operacyjnymi, każdy z własną zduplikowaną przestrzenią procesową, pamięcią masową i pamięcią RAM. Na początku sprawiało to, że VDI było niezwykle nieefektywne. Jednak w ostatnich latach zaawansowane systemy VDI — skupione przede wszystkim na platformach wirtualizacyjnych i pamięci masowej — zajęły się wieloma z tych problemów poprzez deduplikację pamięci i przestrzeni dyskowej, używanie wspólnych plików rozruchowych i inne techniki. W rzeczywistości, wbrew większości założeń, może się nawet zdarzyć, że VDI może przewyższyć tradycyjny terminal services dla Windows, ponieważ platforma hypervisora jest w stanie obsługiwać zarządzanie pamięcią i przełączanie zadań jeszcze wydajniej niż sam Windows (zjawisko zaobserwowane po raz pierwszy na początku lat 2000., kiedy w niektórych przypadkach Windows działał szybciej po zwirtualizowaniu na Linux, dzięki czemu zarządzanie pamięcią mogło być częściowo przekazane do leżącego pod spodem systemu Linux, który był bardziej wydajny). Nie zawsze tak jest, ale postępy w obsłudze VDI posunęły się tak daleko, że oba rozwiązania są często dość zbliżone. Ponownie jednak jest to czynnik czyniący VDI bardziej atrakcyjnym w świecie Windows, ale nie tak dramatycznie w świecie poza-Windows, gdzie natywne zarządzanie zadaniami OS jest zazwyczaj bardziej wydajne, a VDI pozostawałoby zbędnym narzutem.

Innym obszarem, w którym VDI konsekwentnie wykazuje większą wydajność niż terminal services, są środowiska z bogatą grafiką renderowaną, takie jak CAD i edycja wideo. Obszary, które nadal mocno skłaniają się ku dedykowanemu sprzętowi, mają tendencję do przechodzenia na VDI zamiast terminal services ze względu na duże inwestycje w możliwości GPU w ramach rozwiązań VDI. Nie jest to scenariusz uniwersalny, ale w sytuacjach, gdzie musi odbywać się intensywne renderowanie graficzne, warto zbadać możliwość, że VDI może działać znacznie lepiej.

Ze względu na sposób zarządzania VDI, jest ono często zarezerwowane tylko dla bardzo dużych wdrożeń, gdzie skala — w liczbie użytkowników końcowych objętych rozwiązaniem — może być wykorzystana do przezwyciężenia części kosztów implementacji. Terminal services natomiast, ze względu na bardziej skalowalny koszt, często można wdrożyć w mniejszych środowiskach lub dla podzbiorów użytkowników bardziej ekonomicznie. Żadne z rozwiązań nie jest powszechne w bardzo małym środowisku obejmującym zaledwie kilku użytkowników, choć pewne osobliwe zjawisko ręcznie zarządzanego VDI sprawiałoby, że VDI byłoby prawdopodobnie bardziej efektywne niż terminal services dla wyjątkowo małej liczby użytkowników — być może mniej niż dziesięciu — gdzie VDI jest traktowane bardziej jak indywidualne serwery, a nie jako ujednolicone środowisko VDI.

Z nielicznymi wyjątkami — wynikającymi przede wszystkim z narzutu licencyjnego tworzonego przez ekosystem desktopów Windows w środowisku zwirtualizowanym — de facto punktem wyjścia dla systemów zdalnego dostępu użytkowników końcowych jest założenie jako punktu startowego technologii terminal server i sięganie po bardziej skomplikowane i kosztowniejsze rozwiązania VDI dopiero wtedy, gdy terminal services okazuje się niezdolny do spełnienia wymagań technicznych danego scenariusza. Dla wszelkich praktycznych celów VDI jest awaryjną, metodą siłową, umożliwiającą działanie wirtualizacji użytkowników końcowych tam, gdzie preferowane metody zawodzą.