Klient chciał VDI. Bacznie przyglądał się połączeniu SimpliVity + VDI Citrix Virtual Desktop. Dla wszystkich operatorów, pracowników biur w miastach itd. W pierwszej fali migracji było pięć tysięcy użytkowników, dlatego nalegali na testy obciążeniowe. VDI może zacząć spowalniać lub po prostu zwolnić — i nie zawsze dzieje się tak z powodu problemów z kanałem. Kupiliśmy bardzo mocny pakiet testowy specjalnie do VDI i obciążaliśmy infrastrukturę, aż przestała działać z powodu dysków i procesora.
Potrzebujemy więc plastikowej butelki, oprogramowania LoginVSI do zaawansowanych testów VDI. Mamy go z licencjami na 300 użytkowników. Potem wzięliśmy sprzęt HPE SimpliVity 380 w zestawie odpowiednim do maksymalnej gęstości użytkowników na jeden serwer, utworzyliśmy maszyny wirtualne z dobrą subskrypcją, zainstalowaliśmy na nich biurowe oprogramowanie na Win10 i zaczęliśmy testować.
Zaczynamy!
System
Dwa węzły (serwery) HPE SimpliVity 380 Gen10. Na każdym:
- 2 x Intel Xeon Platinum 8170 26c 2.1Ghz.
- Pamięć RAM: 768GB, 12 x 64GB LRDIMMs DDR4 2666MHz.
- Główny kontroler dysków: HPE Smart Array P816i-a SR Gen10.
- Dyski twarde: 9 x 1.92 TB SATA 6Gb/s SSD (w konfiguracji RAID6 7+2, czyli to model Medium w terminach HPE SimpliVity).
- Karty sieciowe: 4 x 1Gb Eth (dane użytkowników), 2 x 10Gb Eth (backend SimpliVity i vMotion).
- Specjalne wbudowane karty FPGA w każdym węźle do deduplikacji/kompresji.
Węzły połączone są między sobą interkoneksją 10Gb Ethernet bez zewnętrznego przełącznika, który jest używany jako backend SimpliVity i do przesyłania danych maszyn wirtualnych przez NFS. Dane maszyn wirtualnych w klastrze są zawsze lustrzane między dwoma węzłami.
Węzły są połączone w klaster Vmware vSphere zarządzany przez vCenter.
Do przeprowadzenia testów uruchomione są kontroler domeny i broker połączeń Citrix. Kontroler domeny, broker i vCenter zostały przeniesione do osobnego klastra.
Jako testowa infrastruktura uruchomiono 300 wirtualnych pulpitów w konfiguracji Dedicated – Full Copy, co oznacza, że każdy pulpit to pełna kopia oryginalnego obrazu maszyny wirtualnej i zachowuje wszystkie zmiany dokonane przez użytkowników.
Każda maszyna wirtualna ma 2vCPU i 4GB RAM:
Na maszyny wirtualne zainstalowano następujące oprogramowanie wymagane do przeprowadzenia testów:
- Windows 10 (64-bit), wersja 1809.
- Adobe Reader XI.
- Citrix Virtual Delivery Agent 1811.1.
- Doro PDF 1.82.
- Java 7 Update 13.
- Microsoft Office Professional Plus 2016.
Między węzłami — synchronna replikacja. Każdy blok danych w klastrze ma dwie kopie. Oznacza to, że pełny zestaw danych jest obecnie na każdym z węzłów. Przy klastrze z trzema lub więcej węzłami — kopie bloków są w dwóch różnych miejscach. Przy tworzeniu nowej VM tworzona jest dodatkowa kopia na jednym z węzłów klastra. W przypadku awarii jednego z węzłów wszystkie VM, wcześniej uruchomione na nim, są automatycznie uruchamiane ponownie na innych węzłach, gdzie mają swoje repliki. Jeśli węzeł jest niedostępny przez dłuższy czas, zaczyna się stopniowe przywracanie nadmiarowości, a klaster ponownie wraca do rezerwacji N+1.
Równoważenie i przechowywanie danych odbywa się na poziomie programowego magazynu SimpliVity.
Maszyny wirtualne uruchamiają klastry wirtualizacji, które rozmieszczają je w programowym magazynie. Same stanowiska robocze opierały się na typowym szablonie: do testu zaadoptowano stanowiska finansistów i operacyjnych (to dwa różne szablony).
Testowanie
Do testowania użyto kompleksu oprogramowania LoginVSI 4.1. Komplex LoginVSI, składający się z serwera zarządzającego i 12 maszyn do testowych połączeń, został wdrożony na oddzielnym fizycznym hoście.
Testy przeprowadzono w trzech trybach:
Tryb Benchmark — obciążenie 300 Knowledge workers i 300 Storage workers.
Tryb Standard — obciążenie 300 Power workers.
Aby umożliwić pracę Power workers i zwiększyć różnorodność obciążenia, do kompleksu LoginVSI dodano bibliotekę dodatkowych plików Power Library. W celu zapewnienia powtarzalności wyników wszystkie ustawienia testowego środowiska pozostały domyślne.
Testy Knowledge i Power workers symulują rzeczywiste obciążenie użytkowników pracujących na wirtualnych stacjach roboczych.
Test Storage workers stworzono specjalnie do testowania systemów przechowywania danych, jest daleki od rzeczywistych obciążeń i w dużej mierze polega na pracy użytkownika z dużą ilością plików różnych rozmiarów.
W trakcie testowania użytkownicy logują się do stacji roboczych przez 48 minut, mniej więcej co dziesięć sekund po jednym użytkowniku.
Wyniki
Głównym rezultatem testowania LoginVSI jest metryka VSImax, która jest obliczana na podstawie czasu realizacji różnych zadań uruchamianych przez użytkownika. Na przykład: czas otwarcia pliku w notatniku, czas kompresji pliku w 7-Zip itd.
Szczegółowy opis obliczania metryk dostępny jest w oficjalnej dokumentacji dotyczącej .
Innaczej mówiąc, LoginVSI powtarza typowy wzorzec obciążenia, symulując działania użytkownika w pakiecie biurowym, podczas czytania PDF itd., i mierzy różne opóźnienia. Istnieje krytyczny poziom opóźnień (wszystko się zacina, praca staje się niemożliwa), do osiągnięcia którego uznaje się, że maksymalna liczba użytkowników nie została osiągnięta. Jeśli czas reakcji wynosi 1000 ms szybciej niż ten stan 'wszystko się zacina', uznaje się, że system działa normalnie i można dodać kolejne osoby.
Oto główne metryki:
Metryka
Podejmowane działania
Szczegółowe opis
Obciążane komponenty
NSLD
Czas otwarcia pliku tekstowego
o wielkości 1500 Kb
Uruchamiany jest notatnik i
otwiera losowy dokument o wielkości 1500 Kb, który został skopiowany z puli
zasobów
CPU i I/O
NFO
Czas otwarcia okna dialogowego
w notatniku
Otwieranie pliku VSI-Notepad [Ctrl+O]
CPU, RAM i I/O
ZHC*
Czas tworzenia pliku Zip z silną kompresją
Kompresja lokalnego
losowego pliku w formacie .pst o rozmiarze 5MB, który został skopiowany z
puli zasobów
CPU i I/O
ZLC*
Czas tworzenia pliku Zip ze słabą kompresją
Kompresja lokalnego
losowego pliku w formacie .pst o rozmiarze 5MB, który został skopiowany z
puli zasobów
I/O
CPU
Obliczanie dużej
tablicy losowych danych
Tworzenie dużej tablicy
losowych danych, które będą używane w timerze I/O
CPU
Podczas testowania początkowo obliczana jest podstawowa metryka VSIbase, która pokazuje szybkość realizacji zadań bez obciążenia systemu. Na jej podstawie określa się próg VSImax, który wynosi VSIbase + 1000 ms.
Wnioski dotyczące wydajności systemu są podejmowane na podstawie dwóch metryk: VSIbase, określającej szybkość działania systemu, oraz progu VSImax, określającego maksymalną liczbę użytkowników, jaką system znieść bez znaczącej degradacji.
300 metryk dla pracowników wiedzy benchmark
Pracownicy wiedzy to użytkownicy, którzy regularnie obciążają pamięć, procesor i IO różnymi często małymi szczytami. Oprogramowanie emuluje obciążenie wymagających użytkowników biurowych, jakby nieustannie coś klikali (PDF, Java, pakiet biurowy, przeglądanie zdjęć, 7-Zip). W miarę dodawania użytkowników od zera do 300 opóźnienie dla każdego płynnie rośnie.
Dane statystyczne VSImax:
VSIbase = 986 ms, próg VSI nie został osiągnięty.
Statystyka obciążenia na systemie przechowywania z monitoringu SimpliVity:
Przy tym typie obciążenia system znosi wzrost obciążenia praktycznie bez degradacji wydajności. Czas realizacji zadań użytkowników rośnie płynnie, czas reakcji systemu nie zmienia się w trakcie testowania i wynosi do 3 ms przy zapisie i do 1 ms — przy odczycie.
Wynik: 300 użytkowników knowledge pracuje bez żadnych problemów na obecnym klastrze i nie przeszkadzają sobie nawzajem, osiągając przekaźnictwo pCPU/vCPU 1 do 6. Całkowite opóźnienia przy wzroście obciążenia rosną równomiernie, ale osiągnięty nie został ustalony limit.
300 punktów próbnych Storage workers
To użytkownicy, którzy ciągle zapisują i odczytują w proporcji 30 do 70. Test ten został przeprowadzony raczej w celach eksperymentalnych. Dane statystyczne VSImax:
VSIbase = 1673, próg VSI osiągnięty na 240 użytkownikach.
Statystyka obciążenia na systemie przechowywania z monitoringu SimpliVity:
Ten typ obciążenia to w zasadzie test obciążeniowy systemu przechowywania. Podczas jego realizacji każdy użytkownik zapisuje na dysku wiele losowych plików o różnych rozmiarach. W tym przypadku widać, że przy przekroczeniu pewnego progu obciążenia u części użytkowników rośnie czas realizacji zadań związanych z zapisem plików. Przy tym obciążenie na systemie przechowywania, procesorze i pamięci hostów nie zmienia się znacznie, dlatego obecnie nie można dokładnie określić, z czym związane są opóźnienia.
Wnioski dotyczące wydajności systemu na podstawie tego testu można formułować tylko w porównaniu z wynikami testów na innych systemach, ponieważ takie obciążenia są syntetyczne i nierealistyczne. Niemniej jednak, ogólnie test przeszedł całkiem nieźle. Do 210 sesji wszystko działało dobrze, a potem zaczęły się niejasne reakcje, które w żaden sposób nie były śledzone poza Login VSI.
300 Power workers
To są użytkownicy, którzy cenią procesory, pamięć i wysokie IO. Ci „zaawansowani użytkownicy” regularnie uruchamiają złożone zadania z długimi szczytami, takie jak instalacja nowego oprogramowania i rozpakowywanie dużych archiwów. Statystyki VSImax:
VSIbase = 970, próg VSI nie został osiągnięty.
Statystyka obciążenia na systemie przechowywania z monitoringu SimpliVity:
Podczas testowania osiągnięto próg obciążenia procesorów na jednym z węzłów systemu, ale nie miało to istotnego wpływu na jego działanie:
W takim przypadku system utrzymuje wzrost obciążenia bez istotnej degradacji wydajności. Czas realizacji zadań użytkowników rośnie płynnie, czas reakcji systemu nie zmienia się podczas testowania i wynosi do 3 ms przy zapisie i do 1 ms — przy odczycie.
Zwykłe testy były niewystarczające dla klienta, więc poszliśmy dalej: podnieśliśmy parametry VM (liczbę vCPU, aby ocenić wzrost nadpisania i rozmiar dysku) i dodaliśmy dodatkowe obciążenie.
Podczas przeprowadzania dodatkowych testów użyto następującej konfiguracji stanowiska:
Rozwiedziono 300 wirtualnych pulpitów w konfiguracji 4vCPU, 4GB RAM, 80GB HDD.
Konfiguracja jednej z maszyn testowych:
Maszyny zostały rozwinięte w wariancie Dedicated – Full Copy:
300 pracowników wiedzy benchmark z nadpisaniem 12
Dane statystyczne VSImax:
VSIbase = 921 ms, próg VSI nie został osiągnięty.
Statystyka obciążenia na systemie przechowywania z monitoringu SimpliVity:
Uzyskane wyniki są analogiczne do testowania poprzedniej konfiguracji VM.
300 pracowników o dużej mocy z nadpisaniem 12
Dane statystyczne VSImax:
VSIbase = 933, próg VSI nie został osiągnięty.
Statystyka obciążenia na systemie przechowywania z monitoringu SimpliVity:
Podczas tego testu również osiągnięto próg obciążenia procesorów, ale nie miało to istotnego wpływu na wydajność:
Uzyskane wyniki są analogiczne do testowania poprzedniej konfiguracji.
Co się stanie, jeśli uruchomimy obciążenie przez 10 godzin?
Teraz zobaczmy, czy wystąpi „efekt kumulacji”, i uruchamiamy testy przez 10 godzin z rzędu.
Długoterminowe testy i opis sekcji powinny być skierowane na to, co chcieliśmy sprawdzić, czy wystąpią jakieś problemy z farmą podczas długiego obciążenia.
300 pracowników wiedzy benchmark + 10 godzin
Dodatkowo przeprowadzono testowanie wariantu obciążenia 300 pracowników wiedzy z dalszą pracą użytkowników przez 10 godzin.
Dane statystyczne VSImax:
VSIbase = 919 ms, próg VSI nie został osiągnięty.
Dane statystyki VSImax szczegółowe:
Na wykresie widać, że w trakcie całego testu nie zaobserwowano żadnej degradacji wydajności.
Statystyka obciążenia na systemie przechowywania z monitoringu SimpliVity:
Wydajność systemu przechowywania pozostaje na tym samym poziomie przez cały czas trwania testu.
Dodatkowe testowanie z wprowadzeniem obciążenia syntetycznego
Klient poprosił o dodanie obciążenia na dysk. W tym celu do systemu przechowywania w każdej z maszyn wirtualnych użytkowników dodano zadanie uruchamiające syntetyczne obciążenie dysku w momencie logowania użytkownika. Obciążenie było generowane przez narzędzie fio, umożliwiające ograniczenie obciążenia dysku w zależności od liczby IOPS. Na każdej maszynie uruchamiano zadanie generujące dodatkowe obciążenie na poziomie 22 IOPS w proporcjach 70%/30% Losowe Odczyty/Zapisy.
Benchmark 300 pracowników wiedzy + 22 IOPS na użytkownika
Podczas początkowego testowania stwierdzono, że fio generuje znaczne dodatkowe obciążenie na procesorach maszyn wirtualnych. Doprowadziło to do szybkiego przeciążenia hostów CPU i miało duży wpływ na ogólną wydajność systemu.
Obciążenie CPU hostów:
Opóźnienia systemu przechowywania również naturalnie wzrosły:
Niedobór mocy obliczeniowej stał się krytyczny przy około 240 użytkownikach:
W wyniku uzyskanych rezultatów zdecydowano się na przeprowadzenie testów, które mniej obciążają CPU.
Benchmark 230 pracowników biurowych + 22 IOPS na użytkownika
Aby zmniejszyć obciążenie CPU, wybrano typ obciążenia pracowników biurowych, do każdej sesji dodano również po 22 IOPS obciążenia syntetycznego.
Test został ograniczony do 230 sesji, aby nie przekroczyć maksymalnego obciążenia CPU.
Test został uruchomiony z kontynuacją pracy użytkowników przez 10 godzin w celu sprawdzenia stabilności systemu podczas długotrwałej pracy pod obciążeniem bliskim maksymalnemu.
Dane statystyczne VSImax:
VSIbase = 918 ms, próg VSI nie został osiągnięty.
Dane statystyki VSImax szczegółowe:
Na wykresie widać, że w trakcie całego testu nie zaobserwowano żadnej degradacji wydajności.
Dane statystyczne dotyczące obciążenia CPU:
Podczas wykonania tego testu obciążenie CPU hostów było praktycznie maksymalne.
Statystyka obciążenia na systemie przechowywania z monitoringu SimpliVity:
Wydajność systemu przechowywania pozostaje na tym samym poziomie przez cały czas trwania testu.
Obciążenie systemu przechowywania w trakcie testu wyniosło około 6 500 IOPS w proporcji 60/40 (3 900 IOPS - na odczycie, 2 600 IOPS - na zapisie), co daje około 28 IOPS na jedno stanowisko robocze.
Czas odpowiedzi wynosił średnio 3 ms na zapis i do 1 ms na odczyt.
Podsumowanie
W modelowaniu rzeczywistych obciążeń infrastruktury HPE SimpliVity uzyskano wyniki potwierdzające zdolność systemu do obsługi co najmniej 300 maszyn typu Full Clone na dwóch węzłach SimpliVity. W tym czasie czas odpowiedzi systemu przechowywanego był na optymalnym poziomie przez cały czas testowania.
Bardzo podoba nam się podejście do długotrwałych testów i porównania rozwiązań przed wdrożeniem. Możemy także przetestować wydajność w kontekście Twoich obciążeń, jeśli chcesz. Również na innych rozwiązaniach hiperconvergentych. Wspomniany klient obecnie kończy testy na innym rozwiązaniu równolegle. Jego obecna infrastruktura to tylko zbiór komputerów osobistych, domena i oprogramowanie na każdym stanowisku. Przejście na VDI bez testów jest oczywiście dość skomplikowane. Szczególnie trudno zrozumieć rzeczywiste możliwości farmy VDI, nie migrując na nią rzeczywistych użytkowników. Te testy pozwalają szybko ocenić rzeczywiste możliwości danego systemu bez potrzeby angażowania typowych użytkowników. Tak powstało to badanie.
Drugie ważne podejście — klient od razu zaplanował odpowiednie skalowanie. Można dokupić serwer i dodać farmę, na przykład dla 100 użytkowników, wszystko jest przewidywalne pod względem ceny na użytkownika. Kiedy będą potrzebować dodać kolejnych 300 użytkowników, będą wiedzieć, że potrzebują dwóch serwerów w już określonej konfiguracji, a nie przeglądać możliwości modernizacji swojej infrastruktury jako całości.
Interesują mnie możliwości federacji HPE SimpliVity. Biznes jest geograficznie podzielony, więc ma sens instalowanie osobnego urządzenia VDI w odległym biurze. W federacji SimpliVity każda maszyna wirtualna jest replikowana według harmonogramu z możliwością bardzo szybkiej replikacji między geograficznie rozdzielonym klastrami bez obciążenia łącza — to wbudowane kopie zapasowe na bardzo wysokim poziomie. Podczas replikacji maszyn wirtualnych między lokalizacjami, łącze jest wykorzystywane w minimalnym stopniu, co daje możliwości budowania bardzo interesujących architektur DR przy istnieniu jednego centrum zarządzania i wielu zdecentralizowanych lokalizacji przechowywania.
To wszystko razem pozwala szczegółowo ocenić także stronę finansową, nałożyć koszty VDI na plany wzrostu firmy oraz zrozumieć, jak szybko rozwiązanie się zwróci i jak będzie działać. Ponieważ każdy VDI to rozwiązanie, które ostatecznie oszczędza wiele zasobów, ale jednocześnie prawdopodobnie nie ma ekonomicznie uzasadnionej możliwości jego zmiany w ciągu 5–7 lat użytkowania.
W razie pozostałych pytań, które nie dotyczą komentarzy, proszę pisać na mój e-mail mk@croc.ru.
Źródło: habr.com
