Zastanawialiście się kiedyś, co robi skaner z stacją VDI? Na początku wszystko wygląda dobrze: skaner jest widoczny jako zwykłe urządzenie USB i jest "przezroczysty" dla maszyny wirtualnej. Potem użytkownik wydaje polecenie skanowania i wszystko się sypie. W najlepszym przypadku — sterownik skanera, w gorszym — oprogramowanie skanera po kilku minutach, a to może też wpłynąć na innych użytkowników klastra. Dlaczego? Ponieważ, aby uzyskać pięciomegabitowy skompresowany obrazek, trzeba przesłać przez USB 2.0 o dwa-trzy rzędy więcej danych. Przepustowość szyny to 480 Mbit/s.
Więc należy przetestować trzy rzeczy: UX, peryferia i bezpieczeństwo — koniecznie. Jest różnica, jak testować. Można zainstalować agentów lokalnie, na każdej wirtualnej stacji roboczej. To dość budżetowe, ale nie pokazuje obciążenia kanału i nie zawsze poprawnie liczy obciążenie procesora. Druga opcja — rozwinąć w innym miejscu potrzebną liczbę robotów-emulatorów i zacząć je łączyć z rzeczywistymi stanowiskami pracy jak prawdziwymi użytkownikami. Pojawi się obciążenie od protokołu przesyłu strumieniowego obrazu (dokładniej, zmienionych pikseli), analiza i wysyłanie pakietów sieciowych, a obciążenia kanału staną się jasne. Kanał jest w ogóle bardzo rzadko sprawdzany.
UX to prędkość wykonywania różnych działań przez końcowego użytkownika. Istnieją pakiety testów, które obciążają instalację setkami użytkowników i wykonują typowe dla nich działania: uruchamiają pakiety biurowe, czytają PDF, przeglądają, rzadko-rzadko oglądają porno w godzinach pracy i tak dalej.
Dość dobrym przykładem tego, dlaczego takie testy są ważne z wyprzedzeniem, była ostatnia instalacja. Tam tysiąc użytkowników przechodzi na VDI, mają biuro, przeglądarkę i SAP. Dział IT w firmie jest rozwinięty, więc istnieje kultura testowania obciążenia przed wdrożeniami. Z mojego doświadczenia, zazwyczaj trzeba namawiać klienta na to, ponieważ koszty są duże, a korzyści nie zawsze są oczywiste. Czy są jakieś wyliczenia, gdzie można się pomylić? W rzeczywistości — takie testy ujawniają miejsca, o których myślano, ale nie można ich było przetestować.
Instalacja
Sześć serwerów, konfiguracja wygląda tak:
Nie mieliśmy dostępu do macierzy danych klienta, była ona udostępniana jako usługa z miejsca. Wiemy, że to wszystko jest w technologii all-flash. Jaka dokładnie to macierz, nie wiemy, ale każdy z działów ma po 10 TB. VDI — VMware według wyboru klienta, ponieważ zespół IT już zna ten stos, a całość stosunkowo organicznie dopełnia infrastrukturę. VMware mocno przyzwyczaja do swojego ekosystemu, ale jeśli budżet na zakupy wystarcza — przez lata można nie znać problemów. Ale to często bardzo duże „jeśli”. Mamy dobrą zniżkę, a klient o tym wie.
Zaczynamy testy, ponieważ zespół IT prawie nic nie dopuszcza do produkcji bez wcześniejszych testów. VDI nie jest czymś, co można uruchomić, a potem zaakceptować. Użytkownicy dołączają stopniowo, a z problemami można się zmierzyć po pół roku. Czego, naturalnie, nikt nie chce.
450 „użytkowników” w teście, obciążenie generujemy lokalnie. Robo-użytkownicy wykonują różne działania jednocześnie, mierzymy czas każdej operacji przez kilka godzin pracy:
Patrzymy, jak będą się zachowywać serwery i macierz. Czy VDI będzie w stanie stworzyć potrzebną liczbę wirtualnych miejsc pracy i tak dalej. Ponieważ klient nie poszedł drogą hiperkonwergencji, a wybrał macierz flashową, trzeba było również sprawdzić poprawność rozmiarów.
Ogólnie rzecz biorąc, jeśli coś gdzieś zwalnia — trzeba zmienić ustawienia farmy VDI, w szczególności przydział zasobów między użytkownikami różnych kategorii.
Peryferia
Z peryferiami zazwyczaj zdarzają się trzy sytuacje:
- Klient po prostu mówi, że nic nie podłączamy (no, oprócz słuchawek, te zwykle są widoczne „z pudełka”). Ostatnie pięć lat bardzo rzadko widziałem słuchawki, które nie podłączyłyby się same i które nie byłyby rozpoznane przez VMware.
- Drugie podejście — bierzemy i w ramach projektu wdrożenia VDI zmieniamy peryferia: bierzemy urządzenia przetestowane przez nas i wspierane przez klienta. Taki przypadek z oczywistych powodów jest rzadki.
- Trzecie podejście — podłączamy istniejący sprzęt.
O problemie ze skanerami już wiecie: trzeba zainstalować oprogramowanie pośredniczące na stacji roboczej (cienki klient), które odbiera strumień USB, kompresuje obraz i wysyła go do VDI. Ze względu na szereg szczegółów, nie zawsze jest to możliwe: podczas gdy na klientach Windows (komputerach domowych i cienkich klientach) wszystko działa dobrze, to dla wersji *nix zazwyczaj dostawca VDI wspiera jakiś konkretny dystrybucję, a zaczynają się tańce z bębnem, jak w przypadku klientów Mac. Z mojej pamięci mało kto podłączał lokalne drukarki z instalacji Linux w taki sposób, aby w trakcie debugowania działały bez ciągłych telefonów do wsparcia. Ale to już postęp, jeszcze jakiś czas temu — po prostu, aby to działało.
Wideokonferencje — wszyscy klienci prędzej czy później chcą, aby to działało i działało dobrze. Jeśli właściwie zaprojektowałeś farmę, to działa dobrze, jeśli nie — otrzymujemy sytuację, w której w trakcie audiokonferencji wzrasta obciążenie łącza, dodatkowo pojawia się problem, że obraz jest słaby (brak full HD, twarz z 9–16 pikseli). Pojawia się bardzo silne dodatkowe opóźnienie, gdy występuje pętla między klientem, stacją roboczą VDI, serwerem VKS, stamtąd drugim VDI i drugim klientem. Prawidłowo łączyć bezpośrednio z klienta do serwera VKS, co wymaga zainstalowania jeszcze jednego składnika.
USB-keys — z nimi w ogóle nie ma problemów, karty smart i tym podobne, wszystko działa od zaraz. Problemy mogą występować ze skanerami kodów kreskowych, drukarkami etykiet, maszynami (tak, było i takie), kasami. Ale wszystko da się rozwiązać. Z niuansami i nie bez niespodzianek, ale ostatecznie da się to załatwić.
Kiedy użytkownik ogląda YouTube z stacji VDI — to najgorsza sytuacja zarówno dla obciążenia, jak i dla łącza. Większość rozwiązań oferuje przekierowanie wideo HTML5. Skondensowany plik jest przesyłany do klienta, gdzie jest wyświetlany. Lub klientowi przesyłany jest link do bezpośredniego połączenia przeglądarki z hostem wideo (to rzadziej).
Bezpieczeństwo
Bezpieczeństwo zazwyczaj iskrzy w miejscach połączeń komponentów i na urządzeniach klienckich. Przy połączeniach w jednej ekosystemie wszystko powinno działać dobrze na papierze. W praktyce w 90% przypadków coś wciąż trzeba poprawić. W ostatnich latach bardzo przydatnym zakupem Vmware stało się włączenie do ekosystemu MDM do zarządzania urządzeniami w firmie. VMware wprowadziło ostatnio ciekawe load balancery (dawniejsza Avi Networks), które umożliwiają rozwiązanie problemu rozdzielania strumieni rok po oddaniu VDI, na przykład. Kolejną czysto vmwarową cechą jest dobra optymalizacja oddziałów dzięki ich świeżemu zakupowi, kiedy przejęli firmę VeloCloud, która tworzy SD-WAN dla sieci oddziałowych.
Z punktu widzenia użytkownika końcowego architektura i dostawca są prawie niewidoczni. Globalnie ważne jest, że istnieje klient na każde urządzenie, można się połączyć z tabletu, Maca, cienkiego klienta Windows. Były nawet klienci dla telewizorów, ale teraz, na szczęście, już ich nie ma.
Cechą instalacji VDI obecnie jest to, że użytkownik końcowy w domu po prostu nie ma komputera. Często jest to słaby tablet z Androidem (czasami nawet z myszą lub klawiaturą), a czasem można mieć szczęście i dostać komputer na Windows XP. Który, jak się można domyślić, przez jakiś czas nie był aktualizowany. I już nigdy się nie zaktualizuje. Albo bardzo słabe maszyny, na których klient się nie instaluje, aplikacje nie działają, użytkownik nie może pracować. Na szczęście nawet bardzo słabe urządzenia są odpowiednie (nie zawsze komfortowo, ale są odpowiednie), i to jest uważane za dużą zaletę VDI. Jeśli chodzi o bezpieczeństwo — należy testować kompromitację systemów klienckich. To zdarza się dosyć często.
W świetle zaleceń Rospotrebnadzoru dotyczących organizacji pracy przedsiębiorstw w warunkach ryzyka COVID-19, podłączenie do swoich miejsc pracy w biurze jest bardzo aktualne. Wydaje się, że ta sytuacja będzie trwać długo, a tak, jeśli myśleliście o VDI — można zacząć testować. Przyda się. Zaleceń jest wiele, wyjaśnień . Ważne, że za pomocą VDI można także przebudować pomieszczenia, aby spełnić wymagania. Regulator wprowadza określone normy dystansowania. Na przykład w biurze o powierzchni 50 m² nie może przebywać więcej niż pięciu pracowników.
Jeśli masz pytania dotyczące VDI, które nie powinny być komentowane — oto mój adres e-mail: SSkryl@croc.ru.
Źródło: habr.com
