Wirtualizacja znajduje coraz szersze zastosowanie w wielu obszarach działania infrastruktury informatycznej przedsiębiorstw. Windows Server 2008 R2 wprowadza technologie znane dotychczas z produktów innych firm, zwiększając tym samym możliwości wykorzystania technologii wirtualizacyjnych. W niniejszym artykule przedstawione zostaną rozwiązania infrastruktury wirtualnych pulpitów Virtual Desktop Infrastructure, których działanie polega na zastosowaniu konsolidacji serwerowej w oparciu o hosty Hyper-V wraz z usługami zdalnego pulpitu Remote Desktop Services.

Architektura

Przed przystąpieniem do konfiguracji trzeba wybrać rodzaj wdrażanych pulpitów wirtualnych, tj. pulpit personalny lub standaryzowany. Wspólną cechą obu rozwiązań jest centralizacja zarządzania i przechowywania pulpitów na wirtualnych komputerach uruchamianych na hostach wirtualizacji. Różnice pojawiają się w zakresie przechowywania danych i ustawień personalnych użytkownika, które zapamiętywane są tylko w prywatnym pulpicie wirtualnym, podczas gdy w przypadku standaryzowanych pulpitów zmiany są usuwane zaraz po zakończeniu sesji użytkownika. Pulpity osobiste przypisuje się użytkownikowi, nie mogą być, zatem współużytkowane. Jednocześnie użytkownik łączy się zawsze z tą samą maszyną wirtualną. Natomiast zestaw wirtualnych pulpitów przypisywany jest grupie użytkowników, a wybór maszyny wirtualnej, do której użytkownik uzyska dostęp, jest losowy (wg zasady pierwsza wolna).

Rys. 1. Rodzaje wirtualnych pulpitów.

Niezależnie od sposobu, w jaki pulpity będą przydzielane użytkownikom, zestaw komponentów koniecznych do prawidłowej pracy technologii VDI jest niezmienny:

• Remote Desktop Client (RD C) - komponent klienci pozwalający na połączenie ze zdalnym pulpitem i ewentualną integrację zasobów użytkownika ze zdalnym systemem,
• Remote Desktop Web Access (RD WA) - portal publikujący skróty do zdalnych systemów, w zależności od ich przydziału i uprawnień użytkownika,
• Remote Desktop Session Host (RD SH) - działa w trybie przekierowywania żądań, wspomaga proces weryfikacji celu połączenia użytkownika we współpracy z RD Connection Broker,
• Remote Desktop Connection Broker (RD CB) - określa docelowy wirtualny pulpit (maszynę), z którą ma zostać połączony użytkownik, oraz wysyła sygnał uruchomienia wirtualnej maszyny do hosta wirtualizacji,
• Remote Desktop Virtualization Host (RD VH) - integruje rolę wirtualizacji hyper-v z usługami zdalnego pulpit w celu udostępniania maszyn wirtualnych,
• Active Directory Domain Services (AD DS) - przechowuje informacje o grupach
  i użytkownikach oraz o wirtualnych pulpitach, jakie zostały im przydzielone.

Rys. 2. Schemat infrastruktury wirtualnych pulpitów.

Przykładowy schemat komunikacji w środowisku wirtualnych pulpitów:

1. Klient inicjuje połączenie za pośrednictwem portalu Web Access, skrótu RemoteApp lub Desktop Connection.
2. Żądanie zostaje przesłane do hosta sesji (RD SH) działającego w trybie przekierowywania.
3. Host sesji przesyła żądanie do komponentu Connection Broker.
4. RD CB sprawdza, czy istnieje już jakaś sesja dla danego użytkownika. Jeśli tak, pomijany jest etap 5.
5. RD CB wysyła żądanie do hosta wirtualizacji (RD VH) w celu lokalizacji i uruchomienia wirtualnej maszyny dla użytkownika.
6. RD CB przesyła informacje o nazwie maszyny wirtualnej do hosta sesji (RD SH).
7.  Host sesji (RD SH) przekierowuje informacje do klienta, który przesłał żądanie.
8. Użytkownik zostaje połączony z pulpitem znajdującym się w zestawie pulpitów wirtualnych lub prywatnym pulpitem wirtualnym.

W celu dodatkowego zabezpieczenia ruchu między klientem a maszyną dostarczającą wirtualny pulpit należy zastosować komponent Remote Desktop Gateway, dzięki któremu komunikacja odbywać będzie się w bezpiecznym tunelu SSL.

Konfiguracja hostów wirtualizacji

Jednym z najważniejszych komponentów infrastruktury VDI jest host wirtualizacyjny, w ramach, którego uruchamiane są maszyny wirtualne udostępniające środowisko pracy użytkownikom. Serwer pełniący tę funkcję zwiera rolę  Hyper-V dostarczającą mechanizm wirtualizacji (hypervisor) oraz Remote Desktop Virtualization Host pozwalający na współprace z usługami zdalnego pulpitu. By zapewnić skalowanie obciążenia i większe bezpieczeństwo, nie należy łączyć tych ról z innymi komponentami infrastruktury.

Rys. 3. Instalacja hosta wirtualizacji.

Po zakończeniu konfiguracji serwera kolejnym krokiem jest utworzenie nowej maszyny wirtualnej z systemem klienckim. By mechanizmy poprawnie zidentyfikowały zdalny pulpit, trzeba użyć pełnej, kwalifikowanej nazwy maszyny, np. cli01.skalski.info. Jeśli maszyny będą zastosowane w scenariuszu zestawu wirtualnych pulpitów, należy pamiętać o zachowaniu jednakowej ich konfiguracji oraz o stworzeniu snapshotów umożliwiających wycofanie zmian, gdy użytkownik zakończy swoją sesję. W celu wskazania stanu, do jakiego ma powrócić maszyna, w nazwie snapshota trzeba zawrzeć słowo kluczowe RDV_Rollback. W przeciwnym przypadku zmiany nie zostaną usunięte.

Rys. 4. Host wirtualizacji wraz z maszynami wirtualnymi.

Konieczne jest poprawne zdefiniowanie uprawnień i zezwoleń dotyczących połączeń zdalnych dla każdej maszyny wirtualnej, z jaką mają się łączyć klienci. Wśród zadań konfiguracji należy wyróżnić:

• 1. Zezwolenie (włączenie) usługi Remote Desktop.
• 2. Dodanie użytkownika/grupy, mającej łączyć się z daną maszyną, do lokalnej grupy Remote Desktop Users.
• 3. Zezwolenie na zdalne wywołanie RPC (Remote Procedure Call) dla RDS (Remote Desktop Services).
• 4. Utworzenie wyjątku dla Remote Services Management w zaporze systemu Windows.
• 5. Dodanie uprawnień dla protokołu RDP (Remote Desktop Protocol) do wirtualnej maszyny.

Wszystkie wymienione zadania można wykonać ręcznie lub za pomocą skryptu w języku powershell, udostępnionym w Microsoft TechNet Script Center. Dzięki temu konfiguracja i definiowanie uprawnień dla maszyny wirtualnej ogranicza się do wykonania poleceń:

• Set-ExecutionPolicy remotesigned - force
• .\<nazwa_pliku_skryptu>.ps1 - RDVHost <domena\nazwa_hosta_wirtualizacji> - RDUsers <domena\nazwa_uzytkownika_lub_grupy>

Rys. 5. Wynik uruchomienia skryptu konfiguracyjnego.

Konfiguracja wirtualizacji prezentacji

Przygotowane wcześniej serwery utrzymujące maszyny wirtualne wymagają wsparcia ze strony usług zdalnego pulpitu (Remote Desktop Services) oraz Active Directory w celu określenia grupy odbiorców. W podanym dalej przykładzie wszystkie niezbędne komponenty instalowane są na jednym serwerze, rzeczywista implementacja może więc wymagać ich odseparowania dla zachowania bezpieczeństwa oraz wydajności rozwiązania. Należy zainstalować następujące komponenty:

• Remote Desktop Session Host - przekierowuje  sesję klienta zgodnie z parametrami pozyskanymi od pozostałych komponentów, działa w trybie przekierowywania żądań.
• Remote Desktop Connection Broker - kontaktuje się z Active Directory w celu wskazania maszyny wirtualnej, z jaką powinien zostać połączony użytkownik, oraz wydaje polecenia serwerowi wirtualizacji (np. uruchom maszynę).
• Remote Desktop Web Access - służy do publikacji skrótów do środowiska pracy użytkownika na portalu web. Warto zwrócić uwagę, że odbywa się to podobnie jak w przypadku skrótów do zdalnych aplikacji (RemoteApp).

Rys. 6. Instalacja komponentów usług zdalnego pulpitu.

Pierwszym krokiem w konfiguracji jest uprawienie usługi Web Access do generowania listy skrótów do udostępnionych środowisk na serwerze pełniącym rolę Connection Broker. W tym celu należy do lokalnej grupy TS Web Access Computers dodać konto serwera świadczącego usługę Web Access.

Rys. 7. Konfiguracja członków grupy TS WA Computers.

Usługa Web Access wymaga wskazania mechanizmu, za pośrednictwem, którego pobierać będzie informacje o środowisku pracy udostępnionym użytkownikowi. Należy wskazać usługę RD Connection Broker, która wskazuje docelową maszynę wirtualną. Dzięki temu na portalu zostaną utworzone skróty odpowiadające pracy w trybie osobistego pulpitu wirtualnego lub zestawu pulpitów wirtualnych.

Rys. 8. Konfiguracja źródła informacji o opublikowanych zasobach.

Osobisty pulpit wirtualny

Celem wdrożenia prywatnych pulpitów wirtualnych jest stworzenie struktury, w której użytkownik może personalizować swoje środowisko pracy oraz zapisywać w nim dane. Specyficzną cechą tego rozwiązania jest kierowanie użytkownika zawsze do tej samej maszyny wirtualnej. Warto zwrócić uwagę, że użytkownik może posiadać tylko jeden osobisty pulpit, co nie wyklucza korzystania z innych wirtualnych maszyn lub standardowych połączeń RDP. Cała konfiguracja odbywa się w przyjaznym dla administratora kreatorze.

Rys. 9. Konfiguracja VDI dla wdrożenia wirtualnych pulpitów osobistych.

Pierwszym etapem konfiguracji osobistych pulpitów wirtualnych jest wskazanie serwerów wirtualizacji, na których utrzymywane są wirtualne maszyny, przeznaczone dla obszaru pracy użytkowników.

Rys. 10. Dodanie hosta wirtualizacji jako źródło wirtualnych maszyn.

W drugim etapie wybiera się serwer przekierowań, czyli Remote Desktop Session Host, działający w trybie przekierowywania żądań użytkownika. Istnieje też możliwość wskazania serwera alternatywnego, jeśli obsługiwani mają być także starsi klienci Remote Desktop Connection, czyli wersji 6.1 i wcześniejszych. Trzeba pamiętać, że tylko jeden serwer może zostać automatycznie przekonfigurowany w tryb przekierowywania żądań. Dlatego w dużych środowiskach, w których istotne jest równoważenie obciążenia i zapewnienie maksymalnej wydajności, czyli w przypadku posiadania farmy serwerów konieczne jest ich ręczne do konfigurowanie.

Rys. 11. Konfiguracja przekierowań.

Jeśli serwer usługi Web Access nie został ręcznie dodany do grupy TS Web Access Computers na serwerze z funkcją Connection Broker, kreator może automatycznie dołączyć do niej komputer wskazany w kolejnym kroku.

Rys. 12. Współpraca z komponentem Web Access.

W ostatnim kroku kreator podsumowuje wykonaną konfigurację oraz zapewnia przejście do następnego etapu, jakim jest przypisanie użytkownikom osobistych pulpitów (maszyn wirtualnych).

Rys. 13. Podsumowanie konfiguracji.

Przypisania można dokonać na dwa sposoby. Pierwszym jest wykorzystanie kreatora, który wybiera docelową maszynę wirtualną z listy powstałej w wyniku zapytania wszystkich hostów wirtualizacji o posiadane przez nie maszyny wirtualne. Należy pamiętać, że nazwa maszyny musi być zgodna z jej kwalifikowaną nazwą w domenie, w przeciwnym przypadku zostanie zasygnalizowany błąd, a maszyna nie zostanie przypisana.

Rys. 14. Przypisanie wirtualnej maszyny do użytkownika.

Drugą metodą jest wskazanie docelowego pulpitu bezpośrednio z właściwości konta danego użytkownika. W tym celu należy użyć zakładki Personal Virtual Desktop i wskazać nazwę komputera (maszyny wirtualnej), na której ma pracować użytkownik.

Rys.15. Konfiguracja konta użytkownika.

Od tej chwili użytkownik po zalogowaniu się na portalu Web Access np. http://term01.skalski.info/RDWeb zobaczy skrót do swojego osobistego pulpitu wirtualnego w postaci ikony My Desktop. Jej wskazanie spowoduje uruchomienie wirtualnej maszyny, która została wybrana we wcześniejszych etapach konfiguracji, i przekazanie sesji bezpośrednio do niej.

Rys. 16. Połączenie z prywatnym pulpitem wirtualnym.

Zestaw pulpitów wirtualnych

Jeśli użytkownicy nie muszą przechowywać swoich danych w wirtualnych środowiskach lub nie da się przypisać każdemu z nich własnej maszyny wirtualnej, możliwe jest zastosowanie zestawu pulpitów wirtualnych. Zadaniem tego rozwiązania jest zapewnienie standaryzowanego środowiska pracy - identycznego dla każdego użytkownika. Warto zwrócić uwagę, że po zakończeniu sesji wszelkie zmiany zostaną usunięte - ustawienia powrócą do tych zapamiętanych, jako snapshot. Podobnie jak w przypadku osobistych pulpitów wirtualnych, konfiguracja odbywa się z użyciem kreatora.

Rys. 17. Konfiguracja zestawu wirtualnych pulpitów.

Pierwszym krokiem jest wybór maszyn wirtualnych, które mają spójną konfigurację oraz snapshot określający ich początkową konfigurację (należy pamiętać o dodaniu do jego nazwy RDV_Rollback).

Rys. 18. Wybór zestawu maszyn wirtualnych.

Drugim krokiem jest określenie nazwy zestawu, pod jaką będzie widoczny dla użytkownika. Identyczną nazwę będzie miał skrót na portalu Web Access oraz identyfikator zestawu niewidoczny dla użytkownika końcowego.

Rys. 19. Definiowanie zestawu wirtualnych pulpitów.

Użytkownik, będący członkiem grupy uprawnionej do uzyskania dostępu za pośrednictwem usługi zdalnego pulpitu na maszynach wirtualnych, zobaczy na portalu Web Access dodatkowy skrót, pozwalający na uzyskanie dostępu do pierwszej wolnej maszyny wirtualnej z zestawu.

Rys. 20. Połączenie z zestawem wirtualnych pulpitów.

Nawiązanie połączenia przez użytkownika powoduje sprawdzenie dostępnych maszyn wirtualnych i przydzielenie mu pierwszej wolnej. W przypadku, gdy jest wyłączona, zostanie podczas tego procesu uruchomiona, a jeśli jest już uruchomiona użytkownik zostanie automatycznie przekierowany. Po zakończeniu sesji maszyna automatycznie wycofuje swój stan do wcześniej zapisanego w snapshot, wymazując tym samym wszelkie zmiany i zapisane dane.

Rys. 21. Nawiązanie połączenia z wirtualną maszyną.

Warto zwrócić uwagę na zwiększenie elastyczności środowiska przez dodatkową konfigurację środowiska wirtualnych pulpitów. Domyślnie każda uruchomiona maszyna wirtualna będzie ciągle pracować, w konfiguracji można wskazać czas nieaktywności, (jaki upłynie od czasu zakończenia sesji użytkownika), po jakim ma zmienić swój stan na stan hibernacji. Dzięki temu możliwe jest zmniejszenie obciążeń serwerów i kosztów utrzymania środowiska.

Autor:

Kamil Skalski
(MCT, MCITP, MCTS, MCSE+S, MCSA+S, MCP)

Pracuje jako trener i konsultant, należy do grupy pasjonatów Windows Server 2008, wirtualizacji i bezpieczeństwa IT, w wolnym czasie prowadzi blog o tej tematyce oraz dzieli się swoją wiedzą wśród społeczności IT pisząc artykuły oraz występując jako ekspert w ramach Microsoft Technology Summit.