Citrix Virtual Apps and Desktops — architektura, zastosowania oraz różnice między XenApp i XenDesktop

1. Wprowadzenie

Citrix Virtual Apps and Desktops (CVAD) to platforma służąca do centralnego udostępniania użytkownikom aplikacji, pełnych pulpitów wirtualnych oraz dostępu do fizycznych komputerów. Aplikacja lub pulpit działa w centrum danych, chmurze albo na komputerze firmowym, natomiast do urządzenia użytkownika przesyłany jest interaktywny obraz sesji oraz dane wejściowe.

Rozwiązanie umożliwia dostęp z różnych urządzeń i lokalizacji, pozostawiając aplikacje oraz dane pod kontrolą organizacji. Może działać jako:

• Citrix Virtual Apps and Desktops — infrastruktura zarządzająca utrzymywana lokalnie przez organizację;
• Citrix DaaS — usługa chmurowa, w której Citrix utrzymuje warstwę sterującą, a organizacja zarządza zasobami aplikacyjnymi i pulpitami w wybranych lokalizacjach zasobów.

Nazwy XenApp i XenDesktop są nazwami historycznymi. Linia produktowa została przemianowana na Citrix Virtual Apps and Desktops, ale określenia te nadal są powszechnie używane w organizacjach, dokumentacji starszych wersji, nazwach komponentów i rozmowach technicznych.

Spis treści

2. Najważniejsze pojęcie: centralne wykonywanie, zdalna prezentacja

3. XenApp i XenDesktop — skąd wzięły się te nazwy

4. Szczegółowe różnice technologiczne: XenApp a XenDesktop

4.1. XenApp: współdzielony host wielosesyjny

4.2. XenDesktop: VDI single-session; 4.3. Publikowanie aplikacji z VDI

5. Architektura Citrix Virtual Apps and Desktops

6. Jak działa uruchomienie sesji

7. Zalety rozwiązania

8. Przeznaczenie i typowe scenariusze wdrożenia

9. Dobór modelu dostarczania

10. CVAD on-premises a Citrix DaaS

11. Bezpieczeństwo i dobre praktyki

12. Ograniczenia i ryzyka

13. Checklista przed wdrożeniem

14. Jak wybrać między Virtual Apps a Virtual Desktops; 15. Słownik; 16. Podsumowanie

17. Źródła — oficjalna dokumentacja producenta

2. Najważniejsze pojęcie: centralne wykonywanie, zdalna prezentacja

W typowym scenariuszu aplikacja nie wykonuje się na laptopie użytkownika. Działa na maszynie z zainstalowanym Virtual Delivery Agent (VDA). Użytkownik korzysta z aplikacji Citrix Workspace app, która odbiera obraz sesji i przekazuje do niej klawiaturę, mysz, dźwięk, schowek, drukarki lub inne dozwolone urządzenia.

Technologie Citrix HDX optymalizują środowisko zdalne m.in. pod kątem grafiki, multimediów, dźwięku, urządzeń peryferyjnych i zmiennych warunków sieciowych.

3. XenApp i XenDesktop — skąd wzięły się te nazwy

Historycznie były to dwa produkty ukierunkowane na inne modele dostarczania zasobów:

• XenApp rozwijał model Server-Based Computing: wiele sesji użytkowników działało równocześnie na wspólnym systemie serwerowym. Najczęściej publikowano pojedyncze aplikacje, ale można było też udostępniać pełny pulpit serwerowy.
• XenDesktop był ukierunkowany na Virtual Desktop Infrastructure (VDI): użytkownik otrzymywał pojedynczy pulpit oparty na systemie desktopowym, uruchomiony na maszynie wirtualnej lub fizycznej. Pulpit mógł być współdzielony w puli albo przypisany konkretnemu użytkownikowi.

Od generacji 7.x XenApp i XenDesktop korzystały ze wspólnej architektury FlexCast Management Architecture (FMA) oraz wspólnych komponentów zarządzających. Późniejsza zmiana nazwy na Citrix Virtual Apps and Desktops odzwierciedliła połączenie obu modeli w jednej platformie.

Najważniejszy wniosek

Różnicy nie należy upraszczać do zdania „XenApp udostępnia aplikacje, a XenDesktop pulpity”. Dokładniejsze rozróżnienie brzmi:

• XenApp wykorzystywał głównie współdzielony system multi-session, na którym jednocześnie pracuje wielu użytkowników;
• XenDesktop wykorzystywał głównie system single-session, w którym jedna aktywna sesja użytkownika zajmuje jedną maszynę lub instancję systemu.

XenApp mógł publikować cały pulpit serwerowy, a XenDesktop mógł dostarczać aplikacje uruchamiane na desktopowej maszynie wirtualnej. Decydujący jest więc model sesji, izolacji i zasobów, a nie sam wygląd zasobu w portalu użytkownika.

4.1. XenApp: współdzielony host wielosesyjny

Na jednym serwerze lub systemie multi-session uruchomionych jest wiele odseparowanych sesji użytkowników. Każda sesja posiada własny pulpit, procesy i profil, ale użytkownicy współdzielą kernel systemu, zainstalowane aplikacje, CPU i pamięć hosta.

Najważniejsze konsekwencje:

• wysoka liczba użytkowników na host i korzystna ekonomika,
• centralna instalacja oraz aktualizacja aplikacji,
• konieczność testowania zgodności wielosesyjnej,
• ograniczona swoboda instalowania oprogramowania przez użytkownika,
• potrzeba kontroli obciążenia, aby jedna sesja nie degradowała pracy pozostałych,
• awaria hosta wpływa na wszystkie uruchomione na nim sesje.

Opublikowana aplikacja może wyglądać jak aplikacja lokalna: użytkownik nie musi widzieć pełnego pulpitu serwera. Okno programu jest prezentowane na urządzeniu końcowym, choć proces działa na VDA.

4.2. XenDesktop: VDI single-session

Każdy aktywny użytkownik korzysta z osobnego systemu operacyjnego. Może to być maszyna z puli albo maszyna przypisana. Zapewnia to mocniejszą izolację i większą zgodność z aplikacjami desktopowymi, ale wymaga większej ilości zasobów infrastruktury.

Najczęstsze modele VDI:

1. Random pooled, non-persistent — przy każdym logowaniu użytkownik otrzymuje dostępną maszynę z puli. Zmiany systemowe są odrzucane po restarcie; dane użytkownika wymagają odrębnego mechanizmu profili i przechowywania.
2. Static non-persistent — użytkownik wraca do tej samej przypisanej maszyny, ale zmiany systemowe nadal mogą być usuwane po restarcie.
3. Static persistent — użytkownik otrzymuje przypisaną maszynę i zachowuje zmiany. Model daje największą personalizację, lecz zwiększa koszt utrzymania oraz ryzyko rozbieżności konfiguracji.
4. Remote PC Access — broker Citrix zapewnia bezpieczny zdalny dostęp do fizycznego komputera pracownika, bez przenoszenia jego środowiska na klasyczną maszynę VDI.

4.3. Publikowanie aplikacji z VDI

Platforma może udostępnić pojedynczą aplikację uruchamianą na maszynie single-session. Jest to przydatne, gdy aplikacja:

• nie działa poprawnie na współdzielonym systemie serwerowym,
• wymaga konkretnego desktopowego systemu Windows,
• koliduje z innymi aplikacjami,
• wymaga silniejszej izolacji na poziomie systemu.

Użytkownik widzi wtedy samo okno aplikacji, podobnie jak w modelu Virtual Apps, ale pod spodem zużywana jest cała maszyna single-session.

5. Architektura Citrix Virtual Apps and Desktops

Delivery Controller

Centralny komponent brokeringu i zarządzania. Uwierzytelnia oraz autoryzuje dostęp do zasobów, wybiera właściwy VDA, śledzi sesje i pośredniczy w zestawieniu połączenia. W środowisku produkcyjnym należy wdrażać co najmniej dwa kontrolery dla odporności i skalowania.

Virtual Delivery Agent (VDA)

Agent instalowany na maszynie udostępniającej aplikację lub pulpit. Rejestruje się w Delivery Controllerze, uruchamia sesję i realizuje polityki Citrix. Główne typy to:

• multi-session VDA — wielu użytkowników na jednym systemie;
• single-session VDA — jeden użytkownik na maszynę;
• Linux VDA — dla obsługiwanych dystrybucji Linux;
• wariant przeznaczony do Remote PC Access.

StoreFront / Citrix Workspace

Warstwa prezentująca użytkownikowi przydzielone aplikacje i pulpity. StoreFront jest komponentem utrzymywanym przez klienta, natomiast środowiska Citrix DaaS mogą korzystać z usług dostępu oferowanych w chmurze.

Citrix Workspace app

Klient na urządzeniu użytkownika. Odpowiada za logowanie, prezentację zasobów oraz uruchamianie sesji HDX. Dostęp przez przeglądarkę może być alternatywą, lecz zakres funkcji zależy od użytego klienta i platformy.

Citrix Gateway

Zapewnia kontrolowany dostęp z sieci zewnętrznych. Może integrować uwierzytelnianie wieloskładnikowe i zabezpieczać połączenie pomiędzy użytkownikiem a środowiskiem Citrix. W zależności od modelu wykorzystywany jest własny Citrix Gateway/NetScaler albo usługa Citrix Gateway Service.

Studio / Web Studio

Konsola administracyjna służąca do tworzenia katalogów maszyn, Delivery Groups, publikowania aplikacji i pulpitów oraz konfigurowania zasad. Web Studio jest webową generacją konsoli zarządzającej.

Director / Monitor

Narzędzie operacyjne dla administratorów i service desk. Pozwala analizować logowania, aktywne sesje, błędy połączeń, wydajność i doświadczenie użytkownika oraz wykonywać działania wsparcia.

Bazy danych

W lokalnym CVAD baza Site przechowuje konfigurację wdrożenia, a dodatkowe bazy mogą obsługiwać monitoring i Configuration Logging. Dostępność SQL jest kluczowa dla pracy warstwy sterującej. W Citrix DaaS bazy warstwy kontrolnej są utrzymywane przez usługę Citrix.

Machine Catalog i Delivery Group

• Machine Catalog grupuje maszyny o podobnym typie systemu, sposobie zarządzania i przeznaczeniu.
• Delivery Group określa, które maszyny oraz aplikacje lub pulpity są dostępne dla konkretnych użytkowników i grup.

MCS i Citrix Provisioning

Platforma oferuje mechanizmy budowania wielu maszyn ze wspólnego obrazu:

• Machine Creation Services (MCS) — tworzenie i zarządzanie maszynami przez integrację z hypervisorem lub chmurą;
• Citrix Provisioning (PVS) — strumieniowe dostarczanie obrazu systemu do wielu maszyn docelowych.

Wybór zależy od platformy, skali, wymagań operacyjnych, kompetencji zespołu i oczekiwanego modelu aktualizacji.

6. Jak działa uruchomienie sesji

1. Użytkownik otwiera Citrix Workspace app albo portal webowy.
2. Warstwa dostępu uwierzytelnia użytkownika i pokazuje dozwolone zasoby.
3. Użytkownik wybiera aplikację lub pulpit.
4. Delivery Controller sprawdza uprawnienia i wybiera odpowiedni, dostępny VDA.
5. Do klienta trafiają parametry zestawienia połączenia.
6. Citrix Workspace app zestawia sesję HDX z VDA — bezpośrednio albo przez Citrix Gateway.
7. Aplikacja wykonuje się na VDA, a użytkownik otrzymuje zdalny interfejs sesji.
8. Dane sesji są dostępne dla narzędzi monitorujących i wsparcia.

7. Zalety rozwiązania

Centralizacja aplikacji i obrazów

Aplikacje mogą być instalowane oraz aktualizowane w centralnym obrazie zamiast osobno na każdym urządzeniu końcowym. Ogranicza to różnice konfiguracji i przyspiesza dystrybucję zmian.

Bezpieczniejszy dostęp do danych

Dane biznesowe mogą pozostać w kontrolowanym centrum danych lub chmurze. Na urządzenie użytkownika trafia przede wszystkim interaktywny obraz sesji. Polityki mogą ograniczać schowek, dyski lokalne, drukowanie, USB i inne kanały wymiany danych.

Dostęp z wielu urządzeń i lokalizacji

Użytkownicy mogą uzyskiwać dostęp do tego samego zestawu aplikacji z komputerów firmowych, prywatnych, urządzeń mobilnych, terminali i przeglądarek — w granicach polityk organizacji.

Optymalizacja kosztu infrastruktury

Model multi-session pozwala wielu użytkownikom współdzielić host, co zwykle daje wyższą gęstość niż VDI. Organizacja może dobierać model dostarczania do profilu użytkownika zamiast przydzielać każdemu pełną maszynę wirtualną.

Spójne środowisko pracy

Profile, zasady i wspólne obrazy ułatwiają zapewnienie jednolitej konfiguracji. Użytkownik może uzyskać podobne środowisko niezależnie od urządzenia końcowego.

Elastyczne modele dostarczania

Jedna platforma może równolegle obsługiwać aplikacje publikowane, współdzielone pulpity, VDI trwałe i nietrwałe, aplikacje VM-hosted, Linux oraz Remote PC Access.

Skalowanie i automatyzacja

Integracja z hypervisorami i chmurami pozwala tworzyć katalogi z obrazu wzorcowego, zarządzać zasilaniem maszyn oraz skalować zasoby zgodnie z zapotrzebowaniem.

Wsparcie operacyjne

Director/Monitor oraz dane o logowaniu i sesjach ułatwiają analizę problemów z wydajnością, połączeniami i doświadczeniem użytkownika.

8. Przeznaczenie i typowe scenariusze wdrożenia

Publikacja aplikacji biznesowych

Najlepsza dla aplikacji ERP, finansowych, administracyjnych lub starszych programów Windows, które muszą być utrzymywane centralnie i udostępniane wielu użytkownikom.

Preferowany model: Virtual Apps na systemie multi-session, jeśli aplikacja jest z nim zgodna.

Call center i użytkownicy zadaniowi

Pracownicy korzystają z niewielkiego, standardowego zestawu aplikacji i nie wymagają indywidualnej konfiguracji systemu.

Preferowany model: współdzielony pulpit lub aplikacje multi-session.

Praca hybrydowa i zdalna

Organizacja chce zapewnić kontrolowany dostęp do aplikacji bez kopiowania danych na prywatne lub słabiej zarządzane urządzenia.

Preferowany model: Virtual Apps, VDI albo Remote PC Access, zależnie od potrzeb użytkownika.

Kontraktorzy i partnerzy

Zewnętrzni użytkownicy potrzebują dostępu tylko do określonych aplikacji na ograniczony czas.

Preferowany model: publikowane aplikacje z precyzyjnymi politykami dostępu, MFA i ograniczeniem kanałów urządzeń.

Użytkownicy wymagający personalizacji

Programiści, analitycy, projektanci lub specjaliści potrzebują własnych narzędzi, konfiguracji albo zasobów.

Preferowany model: statyczne VDI, często persistent, po analizie wymagań sprzętowych i bezpieczeństwa.

Aplikacje niezgodne z multi-session

Aplikacja wymaga systemu desktopowego, ma konfliktujące zależności albo nie wspiera wielu użytkowników na jednym hoście.

Preferowany model: VM-hosted app lub pełny pulpit VDI.

Bezpieczny dostęp do komputerów biurowych

Organizacja chce umożliwić pracownikom zdalny dostęp do fizycznych stacji roboczych bez zmiany ich środowiska.

Preferowany model: Remote PC Access.

Odporność operacyjna i szybkie uruchomienie stanowisk

Centralne obrazy i dostęp z różnych urządzeń mogą wesprzeć pracę awaryjną, zastępowalność urządzeń końcowych oraz szybki onboarding użytkowników.

11. Bezpieczeństwo i dobre praktyki

• Stosuj MFA dla dostępu zewnętrznego i kont uprzywilejowanych.
• Udostępniaj sesje przez Citrix Gateway lub odpowiednią usługę dostępu; nie publikuj VDA bezpośrednio do internetu.
• Segmentuj warstwę zarządzającą, dostęp użytkowników, VDA, bazy danych i infrastrukturę provisioningową.
• Stosuj zasadę najmniejszych uprawnień w delegowanej administracji oraz Delivery Groups.
• Ogranicz przekierowanie schowka, dysków, USB i drukarek do rzeczywistych potrzeb biznesowych.
• Aktualizuj warstwę sterującą, VDA, Workspace app, StoreFront i Gateway zgodnie ze wspieraną ścieżką.
• Chroń obrazy wzorcowe: skanuj je, wersjonuj i testuj przed publikacją.
• Nie przechowuj danych użytkownika wyłącznie na nietrwałym dysku systemowym VDI.
• Monitoruj nietypowe logowania, awarie rejestracji VDA, opóźnienia logowania i zmiany administracyjne.
• Projektuj nadmiarowo Delivery Controllers, StoreFront, Gateway, SQL oraz komponenty zależne.
• Testuj Local Host Cache lub inne mechanizmy ciągłości odpowiednie dla używanego modelu i wersji.

12. Ograniczenia i ryzyka

• Platforma ma wiele komponentów i wymaga świadomego projektu zależności.
• Niedoszacowanie CPU, RAM, IOPS lub profili użytkowników szybko wpływa na jakość sesji.
• Aplikacje mogą zachowywać się inaczej w środowisku multi-session; wymagają testów funkcjonalnych i wydajnościowych.
• VDI zapewnia większą izolację, ale zwykle zwiększa koszt obliczeń, storage’u i licencji systemowych.
• Persistent VDI może prowadzić do rozbieżności konfiguracji i utrudniać aktualizacje.
• Non-persistent VDI wymaga prawidłowego rozdzielenia systemu, profilu i danych użytkownika.
• Pojedyncza awaria wspólnego komponentu — np. Gateway, StoreFront, SQL lub profilu — może oddziaływać na wielu użytkowników.
• Dobre działanie HDX nie usuwa ograniczeń słabej łączności; opóźnienie, utrata pakietów i przepustowość nadal mają znaczenie.
• Licencje Microsoft RDS, Windows, Citrix i aplikacji biznesowych muszą być zweryfikowane dla wybranego modelu.

13. Checklista przed wdrożeniem

Analiza użytkowników i aplikacji

• Zdefiniowano persony użytkowników i ich wymagania.
• Zinwentaryzowano aplikacje, zależności, licencje i wymagane urządzenia.
• Przetestowano zgodność aplikacji z systemem multi-session.
• Określono, czy użytkownik potrzebuje aplikacji, wspólnego pulpitu, VDI czy Remote PC Access.
• Ustalono wymagania dotyczące personalizacji i trwałości danych.

Projekt

• Wybrano model on-premises albo Citrix DaaS.
• Zaprojektowano HA dla warstwy dostępu i sterowania.
• Oszacowano CPU, RAM, GPU, IOPS, sieć i pojemność profili.
• Wybrano MCS, PVS lub inny wspierany sposób budowania maszyn.
• Zaplanowano profile, dane użytkownika, drukowanie i przekierowania urządzeń.
• Określono zasady dostępu zewnętrznego, MFA i segmentacji.

Pilotaż i produkcja

• Wykonano pilotaż na reprezentatywnej grupie użytkowników.
• Zmierzono czas logowania, zużycie hostów i jakość sesji HDX.
• Przetestowano awarie Controllerów, StoreFront, Gateway, SQL i hostów VDA.
• Przygotowano wersjonowanie obrazu oraz procedurę rollback.
• Skonfigurowano monitoring i progi alarmowe.
• Udokumentowano wsparcie pierwszej i drugiej linii.

14. Jak wybrać między Virtual Apps a Virtual Desktops

Rozpocznij od modelu Virtual Apps, jeżeli aplikacja poprawnie działa na systemie multi-session, użytkownicy mają podobne potrzeby, a priorytetem jest gęstość i centralne utrzymanie.

Wybierz Virtual Desktops, jeżeli użytkownik potrzebuje osobnego systemu, większej personalizacji, aplikacji niezgodnej z systemem serwerowym, specyficznych sterowników lub silniejszej izolacji.

Model hybrydowy jest zwykle najbardziej praktyczny: aplikacje standardowe są publikowane ze współdzielonych hostów, a VDI otrzymują tylko te grupy, które rzeczywiście wymagają jego możliwości.

15. Słownik

• Citrix DaaS — chmurowa usługa dostarczania aplikacji i pulpitów, wcześniej nazywana Citrix Virtual Apps and Desktops service.
• Delivery Controller — komponent brokerujący i zarządzający sesjami.
• Delivery Group — przypisanie maszyn i publikowanych zasobów do użytkowników.
• FMA — FlexCast Management Architecture, wspólna architektura produktów od generacji 7.x.
• HDX — zestaw technologii obsługujących i optymalizujących zdalną sesję użytkownika.
• Hosted Shared Desktop — pełny pulpit udostępniany z wielosesyjnego systemu serwerowego.
• Machine Catalog — logiczna kolekcja podobnie zarządzanych maszyn.
• MCS — Machine Creation Services.
• Multi-session OS — system obsługujący równocześnie wiele sesji użytkowników.
• Non-persistent — model, w którym zmiany systemowe użytkownika nie są trwale zachowywane.
• Persistent — model zachowujący zmiany na przypisanej maszynie.
• PVS — Citrix Provisioning, dostarczanie obrazu systemowego metodą streamingu.
• Single-session OS — system przeznaczony dla jednej aktywnej sesji użytkownika.
• VDA — Virtual Delivery Agent instalowany na maszynie udostępniającej aplikacje lub pulpit.
• VDI — Virtual Desktop Infrastructure.
• XenApp — historyczna nazwa technologii publikowania aplikacji i pulpitów z hostów współdzielonych.
• XenDesktop — historyczna nazwa technologii dostarczania indywidualnych pulpitów VDI.

16. Podsumowanie

Citrix Virtual Apps and Desktops łączy dwa historyczne nurty technologiczne. XenApp zapewniał wysoką gęstość dzięki wielu sesjom na wspólnym systemie serwerowym. XenDesktop zapewniał indywidualne pulpity VDI, większą izolację i personalizację kosztem większego zużycia infrastruktury.

Obecnie oba modele są elementami jednej platformy. Najważniejszą decyzją projektową nie jest wybór starej nazwy produktu, ale dopasowanie typu VDA, trwałości systemu, stopnia personalizacji, izolacji oraz sposobu publikacji do konkretnej grupy użytkowników.

17. Źródła — oficjalna dokumentacja producenta

1. Citrix Virtual Apps and Desktops — centrum dokumentacji

2. Technical overview — Citrix Virtual Apps and Desktops 2607 LTSR

3. Delivery methods — Virtual Apps, VM-hosted apps i VDI

4. Delivery Controllers

5. Citrix DaaS — overview

6. Citrix DaaS — technical security overview

7. XenApp and XenDesktop 7.15 LTSR — dokumentacja archiwalna

8. Citrix Product Matrix — cykl życia produktów