Implementacja VDI

Podejście do wdrożenia VDI zależy od indywidualnej infrastruktury IT, oczekiwanej wydajności i samego rozwiązania VDI.

Jeśli wszyscy użytkownicy będą wykorzystywać do swoich sesji np. szybką LAN, wtedy wybór protokołu może nie być tak istotny. Ale jeżeli pojawiają się użytkownicy w oddziale zamiejscowym, lub łączący się sesjami VDI z domu lub w drodze, wybór protokołu jest sprawą krytyczną. W tej sytuacji lepszą wydajność można uzyskać, stosując protokół Citrix ICA, niż protokół RCA czy PCoIP (chociaż protokół PCoIP, zaadaptowany przez VMware i tak jest lepszy niż RDP). Oczywiście, RDP będzie funkcjonować na takich połączeniach, ale odczucia użytkownika będą gorsze niż z ICA czy PCoIP, kiedy pasmo jest wąskie, a opóźnienia większe.

Zobacz również:

• Przeglądarka Chrome będzie jeszcze jakiś czas akceptować pliki cookie
• Usługa WhatsApp uruchamiana na urządzeniach iOS będzie bardziej bezpieczna
• Cyberobrona? Mamy w planach

VDI może też "skonsumować" sporą część zasobów pamięci masowej, jeżeli każda sesja użytkownika wymaga własnego dysku wirtualnego. Najlepszym sposobem zmniejszenia zapotrzebowania na pamięć VM jest wykorzystanie szablonów VM i generowanie nowych instancji desktopów w biegu - w momencie logowania użytkownika.

Szablon VM jest tworzony z pełnej instalacji desktopowego systemu operacyjnego, która jest przygotowana zgodnie z wszystkimi wymaganiami i ustawieniami aplikacyjnymi. VM użytkownika może być utworzona albo z kompletnej kopii wirtualnego dysku tego szablonu, albo z rozszerzeń opartych na oryginalnym szablonie. Użycie drugiej opcji jest generalnie korzystniejsze. W każdym przypadku, kiedy jest łączona nowa sesja użytkownika, z szablonu robiona jest migawka, a użytkownik loguje się do tej kopii, jako instancji desktopu. Gdy użytkownik się wyloguje, instancja jest usuwana - dysk wirtualny istnieje tak długo, jak długo zalogowany jest użytkownik.

Wdrożenia oparte na szablonach generalnie nie dopuszczają używania statycznych desktopów - każda instancja desktopu jest obecna jedynie w czasie sesji użytkownika. To wymaga, aby reszta infrastruktury była przystosowana do obsługi desktopów "ulotnych".

Istnieją także metody gromadzenia specyficznych użytkowników w specjalne grupy, np. korzystających z call center czy z księgowości itp. Pozwala to na szczegółową kontrolę nad zasobami i aplikacjami - niektóre grupy wymagają np. więcej CPU i RAM.

Zdaniem użytkownika, korzystanie z szablonów VM oznacza pracę w standaryzowanym, zamkniętym środowisku. Jeżeli oprogramowanie, którego użytkownik potrzebuje, nie jest zapewniane przez IT, to nie będzie dostępne. Z punktu widzenia IT nie jest to jednak wada.

Sprzęt po stronie klienckiej

Wybór sprzętu do obsługi "cienkiego klienta" jest łatwiejszy niż rozwiązania programowego, choć nie tak całkiem prosty.

Osprzęt cienkiego klienta można podzielić na kilka grup. Na najniższej półce są jednostki najtańsze, zazwyczaj oparte na Linuksie i zawierające kilka portów USB, port monitora i port Ethernet. Takie rozwiązania są najlepiej dostosowane do systemów, gdzie eksploatuje się stałe aplikacje (np. call center), i gdzie klient korzysta zazwyczaj z jednej aplikacji.

Jeżeli przesuniemy się trochę wyżej, to cienki klient zaczyna wyglądać bardziej jak komputer z zagnieżdżonym systemem desktopowym, oferującym gigabajt lub więcej pamięci, obsługę wielu monitorów itp. W niektórych przypadkach na takim "grubszym" kliencie można uruchamiać lokalne aplikacje, poza łączeniem się z sesjami desktopowymi.

Na samej górze są klienty, które w zasadzie są standardowymi maszynami desktopowymi, wyposażonymi w lokalną pamięć flash zamiast dysku. Zawierają RAM o pojemności kilku gigabajtów, procesory dwurdzeniowe itp. Mogą obsługiwać kilka monitorów i zapewniają wysoką wydajność lokalną. Są nadmiarowe dla prostych usług terminala graficznego czy klientów VDI, ale dobrze dostosowane do uruchomiania stałych aplikacji lokalnych, które wymagają większej wydajności.