Pułapki przy przejściu na VDI: co przetestować wcześniej, aby nie być potwornie bolesnym

Pułapki przy przejściu na VDI: co przetestować wcześniej, aby nie być potwornie bolesnym
Czy zastanawiałeś się kiedyś co skaner robi ze stacją VDI? Na początku wszystko wygląda dobrze: przesyłane jest jak zwykłe urządzenie USB i jest „przezroczyście” widoczne z maszyny wirtualnej. Następnie użytkownik wydaje polecenie skanowania i wszystko idzie do diabła. W najlepszym wypadku – sterownik skanera, gorzej – za kilka minut oprogramowanie skanera, wówczas może to mieć wpływ na pozostałych użytkowników klastra. Dlaczego? Aby uzyskać skompresowany obraz o wielkości pięciu megabajtów, trzeba przesłać dwa do trzech rzędów wielkości więcej danych przez USB 2.0. Przepustowość magistrali wynosi 480 Mbit/s.

Musisz więc przetestować trzy rzeczy: UX, urządzenia peryferyjne i bezpieczeństwo - koniecznością. Jest różnica w sposobie testowania. Możesz zainstalować agentów lokalnie na każdej wirtualnej stacji roboczej. Jest to stosunkowo niedrogie, ale nie pokazuje obciążenia kanału i nie do końca dokładnie oblicza obciążenie procesora. Drugą opcją jest rozmieszczenie wymaganej liczby robotów-emulatorów w innym miejscu i rozpoczęcie podłączania ich do rzeczywistych zadań jako prawdziwi użytkownicy. Dodane zostanie obciążenie z protokołu transmisji strumienia wideo ekranu (a dokładniej zmienionych pikseli), parsowania i wysyłania pakietów sieciowych, a obciążenie kanału stanie się jasne. Kanał jest generalnie bardzo rzadko sprawdzany.

UX to szybkość, z jaką użytkownik końcowy wykonuje różne czynności. Istnieją pakiety testowe, które ładują instalację setkami użytkowników i wykonują dla nich typowe działania: uruchamiają pakiety biurowe, czytają pliki PDF, przeglądają, rzadko oglądają porno w godzinach pracy i tak dalej.

Całkiem dobrym przykładem tego, dlaczego takie testy są ważne na początku, była najnowsza instalacja. Tam do VDI przenosi się tysiąc użytkowników, mają biuro, przeglądarkę i SAP. Dział IT firmy jest rozwinięty, dlatego przed wdrożeniami panuje kultura testów obciążeniowych. Z mojego doświadczenia wynika, że ​​zazwyczaj klienta do tego trzeba przekonać, bo koszty są wysokie, a korzyści nie zawsze są oczywiste. Czy są jakieś obliczenia, w których można popełnić błąd? Tak naprawdę takie testy ujawniają miejsca, o których myśleli, ale nie mogli sprawdzić.

Instalacja

Sześć serwerów, konfiguracja jest następująca:

Pułapki przy przejściu na VDI: co przetestować wcześniej, aby nie być potwornie bolesnym

Nie mieliśmy dostępu do systemu magazynowego klienta, był on de facto udostępniany jako miejsce jako usługa. Ale wiemy, że istnieje all-flash. Nie wiemy, który to all-flash, ale partycje mają 10 TB. VDI - VMware według wyboru klienta, ponieważ zespół IT jest już zaznajomiony ze stosem, a wszystko jest dość organicznie uzupełniane, tworząc kompletną infrastrukturę. VMware jest bardzo „uzależnione” od swojego ekosystemu, ale jeśli masz wystarczający budżet na zakupy, możesz nie mieć żadnych problemów przez lata. Ale często jest to bardzo duże „jeśli”. Mamy dobry rabat i klient o tym wie.

Rozpoczynamy testy, ponieważ zespół IT bez testów prawie niczego nie wypuszcza na produkcję. VDI nie jest czymś, co można uruchomić, a następnie zaakceptować. Użytkownicy ładują się stopniowo i całkiem możliwe jest, że po sześciu miesiącach wystąpią problemy. Czego oczywiście nikt nie chce.

450 „użytkowników” w teście, obciążenie generowane jest lokalnie. Robo-użytkownicy wykonują różne czynności w tym samym czasie, czas każdej operacji mierzymy na przestrzeni kilku godzin pracy:

Pułapki przy przejściu na VDI: co przetestować wcześniej, aby nie być potwornie bolesnym

Pułapki przy przejściu na VDI: co przetestować wcześniej, aby nie być potwornie bolesnym

Pułapki przy przejściu na VDI: co przetestować wcześniej, aby nie być potwornie bolesnym

Zobaczmy, jak zachowają się serwery i systemy pamięci masowej. Czy VDI będzie w stanie utworzyć wymaganą liczbę wirtualnych pulpitów i tak dalej. Ponieważ klient nie poszedł drogą hiperkonwergencji, a zdecydował się na system all-flash, konieczne było sprawdzenie także poprawności wymiarowania.

Pułapki przy przejściu na VDI: co przetestować wcześniej, aby nie być potwornie bolesnym

Pułapki przy przejściu na VDI: co przetestować wcześniej, aby nie być potwornie bolesnym

Pułapki przy przejściu na VDI: co przetestować wcześniej, aby nie być potwornie bolesnym

Pułapki przy przejściu na VDI: co przetestować wcześniej, aby nie być potwornie bolesnym

Pułapki przy przejściu na VDI: co przetestować wcześniej, aby nie być potwornie bolesnym

Pułapki przy przejściu na VDI: co przetestować wcześniej, aby nie być potwornie bolesnym

Właściwie, jeśli coś gdzieś zwalnia, trzeba zmienić ustawienia farmy VDI, w szczególności dystrybucję zasobów pomiędzy użytkownikami różnych kategorii.

Urządzenia peryferyjne

W przypadku urządzeń peryferyjnych występują zazwyczaj trzy sytuacje:

  • Klient po prostu mówi, że nic nie podłączamy (no, poza zestawami słuchawkowymi, zwykle są one widoczne „od razu po wyjęciu z pudełka”). W ciągu ostatnich pięciu lat bardzo, bardzo rzadko widziałem zestawy słuchawkowe, które nie zostały odebrane samodzielnie lub nie zostały odebrane przez VMware.
  • Drugie podejście polega na przyjęciu i wymianie urządzeń peryferyjnych w ramach projektu wdrożeniowego VDI: bierzemy to, co my i klient przetestowaliśmy i wspieraliśmy. Sprawa jest, co zrozumiałe, rzadka.
  • Trzecie podejście polega na przerzuceniu istniejącego sprzętu.

Problem ze skanerami już znasz: musisz zainstalować na stacji roboczej (cienkim kliencie) oprogramowanie pośredniczące, które odbiera strumień USB, kompresuje obraz i wysyła go do VDI. Ze względu na wiele funkcji nie zawsze jest to możliwe: jeśli na klientach Win (komputery domowe i cienkie klienty) wszystko jest w porządku, to w przypadku kompilacji *nix dostawca VDI zwykle obsługuje określoną dystrybucję i rozpoczynają się tańce z tamburynem, ponieważ na klientach Mac. W mojej pamięci niewiele osób podłączało drukarki lokalne z instalacji linuksowych, aby pracowały na etapie debugowania bez ciągłych wezwań do wsparcia. Ale to już jest dobre, jakiś czas temu - nawet do pracy.

Wideokonferencje - wszyscy klienci prędzej czy później chcą, żeby to działało i działało dobrze. Jeśli farma jest zaprojektowana poprawnie, to działa dobrze, jeśli źle, mamy sytuację, że podczas konferencji audio zwiększa się obciążenie kanału, a dodatkowo pojawia się problem, że obraz jest słabo wyświetlany (brak pełnego HD, twarz 9–16 pikseli). Bardzo duże dodatkowe opóźnienie pojawia się, gdy pomiędzy klientem, stacją roboczą VDI, serwerem wideokonferencyjnym i stamtąd drugim VDI i drugim klientem pojawia się pętla. Prawidłowe jest połączenie się bezpośrednio od klienta z serwerem wideokonferencyjnym, co wymaga instalacji kolejnego dodatkowego komponentu.

Klucze USB - nie ma z nimi żadnych problemów, karty inteligentne i tym podobne, wszystko działa od razu po wyjęciu z pudełka. Trudności mogą pojawić się w przypadku skanerów kodów kreskowych, drukarek etykiet, maszyn (tak, było coś takiego) i kas fiskalnych. Ale wszystko jest w trakcie rozwiązywania. Z niuansami i nie bez niespodzianek, ale ostatecznie rozwiązany.

Kiedy użytkownik ogląda YouTube ze stacji VDI, jest to najgorsza sytuacja zarówno dla obciążenia, jak i kanału. Większość rozwiązań oferuje przekierowanie wideo HTML5. Skompresowany plik jest przesyłany do klienta, gdzie jest widoczny. Lub do klienta wysyłany jest link umożliwiający bezpośrednią komunikację między przeglądarką a hostingiem wideo (jest to mniej powszechne).

bezpieczeństwo

Bezpieczeństwo zwykle występuje na interfejsach komponentów i na urządzeniach klienckich. Słowem, na stykach jednego ekosystemu wszystko powinno działać dobrze. W praktyce dzieje się tak w 90% przypadków i nadal trzeba coś dokończyć. W ostatnich latach kolejny zakup Vmvary okazał się bardzo wygodny – dodali do ekosystemu MDM do zarządzania urządzeniami w firmie. Maszyny wirtualne pozyskały ostatnio ciekawe balansery sieciowe (dawniej Avi Networks), które pozwalają zamknąć kwestię dystrybucji przepływów np. rok po zakończeniu VDI. Kolejną cechą czysto własną jest dobra optymalizacja oddziałów dzięki ich świeżym zakupom, gdy 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 niewidoczne. Globalnie ważne jest to, że istnieje klient dla każdego urządzenia; można połączyć się z tabletu, komputera Mac lub cienkiego klienta z systemem Windows. Byli nawet klienci telewizji, ale teraz na szczęście już ich nie ma.

Osobliwością instalacji VDI jest obecnie to, że użytkownik końcowy po prostu nie ma w domu komputera. Często masz słaby tablet z Androidem (czasem nawet z myszą lub klawiaturą), a może nawet będziesz miał szczęście i zdobędziesz komputer z systemem Windows XP. Która, jak można się domyślić, nie była aktualizowana od jakiegoś czasu. I już nigdy nie będzie aktualizowany. Lub bardzo słabe maszyny, na których nie jest zainstalowany klient, aplikacje nie działają, użytkownik nie może pracować. Na szczęście nadają się nawet bardzo słabe urządzenia (nie zawsze wygodne, ale odpowiednie) i jest to uważane za duży plus VDI. Cóż, jeśli chodzi o bezpieczeństwo, konieczne jest przetestowanie kompromisu systemów klienckich. Zdarza się to dość często.

W świetle zaleceń Rospotrebnadzoru w sprawie organizacji pracy przedsiębiorstw zagrożonych COVID-19, bardzo ważne jest połączenie się z miejscami pracy w urzędzie. Wygląda na to, że ta historia będzie trwać długo i tak, jeśli myślałeś o VDI, możesz rozpocząć testowanie. Przyda się. Zalecenia są tutaj, wyjaśnienia tutaj. Co ważne, VDI można również wykorzystać do modernizacji pomieszczeń w celu spełnienia wymogów zgodności. Organ wprowadza pewne standardy zachowania dystansu. Na przykład w biurze o powierzchni 50 mkw. m nie może być więcej niż pięciu pracowników.

Cóż, jeśli masz pytania dotyczące VDI, które nie wymagają komentarza, oto mój e-mail: [email chroniony].

Źródło: www.habr.com

Dodaj komentarz