Klient chciał VDI. Naprawdę przyjrzałem się kombinacji SimpliVity + VDI Citrix Virtual Desktop. Dla wszystkich operatorów, pracowników urzędu miasta i tak dalej. Tylko w pierwszej fali migracji znajduje się pięć tysięcy użytkowników, dlatego nalegali na testy obciążeniowe. VDI może zacząć zwalniać, może spokojnie się położyć - a nie zawsze tak się dzieje ze względu na problemy z kanałem. Specjalnie dla VDI kupiliśmy bardzo wydajny pakiet testowy i ładowaliśmy infrastrukturę do momentu, aż stała się zbyt obciążająca dla dysków i procesora.
Do zaawansowanych testów VDI będziemy więc potrzebować plastikowej butelki i oprogramowania LoginVSI. Posiadamy go z licencjami na 300 użytkowników. Następnie wzięliśmy sprzęt HPE SimpliVity 380 w pakiecie odpowiednim do zadania maksymalnej gęstości użytkowników na serwer, podzieliliśmy maszyny wirtualne z dobrą nadsubskrypcją, zainstalowaliśmy na nich oprogramowanie biurowe na Win10 i rozpoczęliśmy testy.
Chodźmy!
System
Dwa węzły HPE SimpliVity 380 Gen10 (serwery). Na każdym:
- 2x Intel Xeon Platinum 8170 26c 2.1 GHz.
- RAM: 768 GB, 12 modułów LRDIMM 64 GB DDR4 2666 MHz.
- Główny kontroler dysku: HPE Smart Array P816i-a SR Gen10.
- Dyski twarde: 9 x 1.92 TB SATA 6 Gb/s SSD (w konfiguracji RAID6 7+2, czyli jest to model Medium w rozumieniu HPE SimpliVity).
- Karty sieciowe: 4 x 1 Gb Eth (dane użytkownika), 2 x 10 Gb Eth (backend SimpliVity i vMotion).
- Specjalne wbudowane karty FPGA w każdym węźle do deduplikacji/kompresji.
Węzły są połączone ze sobą bezpośrednio za pomocą łącza Ethernet 10 Gb, bez zewnętrznego przełącznika, który służy jako backend SimpliVity i do przesyłania danych maszyny wirtualnej za pośrednictwem NFS. Dane maszyny wirtualnej w klastrze są zawsze dublowane między dwoma węzłami.
Węzły są łączone w klaster Vmware vSphere zarządzany przez vCenter.
Do testów wdrożono kontroler domeny i brokera połączeń Citrix. Kontroler domeny, broker i vCenter są umieszczone w oddzielnym klastrze.
Jako infrastrukturę testową wdrożono 300 wirtualnych desktopów w konfiguracji Dedykowanej – Full Copy, czyli każdy desktop jest pełną kopią oryginalnego obrazu maszyny wirtualnej i zapisuje wszystkie zmiany dokonane przez użytkowników.
Każda maszyna wirtualna ma 2vCPU i 4GB RAM:
Na maszynach wirtualnych zainstalowano następujące oprogramowanie wymagane do testów:
- Windows 10 (64-bitowy), wersja 1809.
- Adobe Reader XI.
- Citrix Virtual Delivery Agent 1811.1.
- Dorota PDF 1.82.
- Aktualizacja Javy 7 13.
- Microsoft Office Professional Plus 2016.
Pomiędzy węzłami - replikacja synchroniczna. Każdy blok danych w klastrze ma dwie kopie. Oznacza to, że teraz w każdym z węzłów znajduje się pełny zestaw danych. W przypadku klastra składającego się z trzech lub więcej węzłów kopie bloków znajdują się w dwóch różnych miejscach. Podczas tworzenia nowej maszyny wirtualnej na jednym z węzłów klastra tworzona jest dodatkowa kopia. W przypadku awarii jednego węzła wszystkie wcześniej działające na nim maszyny wirtualne są automatycznie uruchamiane ponownie w innych węzłach, w których znajdują się ich repliki. Jeśli węzeł ulegnie awarii przez dłuższy czas, rozpoczyna się stopniowe przywracanie redundancji, a klaster powraca do redundancji N+1.
Równoważenie i przechowywanie danych odbywa się na poziomie przechowywania oprogramowania samego SimpliVity.
Maszyny wirtualne obsługują klaster wirtualizacji, który umieszcza je również w magazynie oprogramowania. Same biurka zostały wzięte według standardowego szablonu: na badanie przyszły biurka finansistów i oficerów operacyjnych (są to dwa różne szablony).
Testowanie
Do testów wykorzystano pakiet testów oprogramowania LoginVSI 4.1. Kompleks LoginVSI, składający się z serwera sterującego i 12 maszyn do połączeń testowych, został wdrożony na osobnym hoście fizycznym.
Testowanie przeprowadzono w trzech trybach:
Tryb porównawczy - przypadki obciążenia 300 pracowników wiedzy i 300 pracowników magazynu.
Tryb standardowy - przypadek obciążenia 300 Energetycy.
Aby umożliwić pracownikom Power Workers pracę i zwiększyć różnorodność obciążenia, do kompleksu LoginVSI dodano bibliotekę dodatkowych plików Power Library. Aby zapewnić powtarzalność wyników, wszystkie ustawienia stanowiska testowego pozostały domyślne.
Testy Knowledge i Power Workers symulują rzeczywiste obciążenie użytkowników pracujących na wirtualnych stacjach roboczych.
Test pracowników pamięci masowej został stworzony specjalnie do testowania systemów przechowywania danych; jest daleki od rzeczywistych obciążeń i wymaga głównie pracy użytkownika z dużą liczbą plików o różnych rozmiarach.
Podczas testowania użytkownicy logują się do stacji roboczych na 48 minut z częstotliwością około jednego użytkownika co 10 sekund.
wyniki
Głównym wynikiem testów LoginVSI jest metryka VSImax, która jest kompilowana na podstawie czasu wykonania różnych zadań uruchamianych przez użytkownika. Na przykład: czas na otwarcie pliku w Notatniku, czas na skompresowanie pliku w 7-Zip itp.
Szczegółowy opis obliczania metryk jest dostępny w oficjalnej dokumentacji programu .
Innymi słowy, LoginVSI powtarza typowy wzorzec ładowania, symulując działania użytkownika w pakiecie biurowym, czytając plik PDF itd. i mierząc różne opóźnienia. Występuje krytyczny poziom opóźnień „wszystko zwalnia, nie da się pracować”), przed którym uznaje się, że nie została osiągnięta maksymalna liczba użytkowników. Jeśli czas odpowiedzi jest o 1 ms szybszy niż stan „wszystko działa wolno”, uznaje się, że system działa normalnie i można dodać więcej użytkowników.
Oto główne wskaźniki:
Metryka
Podjęte działania
Szczegółowe описание
Załadowane komponenty
NSLD
Czas otwarcia tekstu
plik o wadze 1 KB
Otwiera się Notatnik i
otwiera losowy dokument o rozmiarze 1 KB, który jest kopiowany z puli
zasoby
Procesor i wejścia/wyjścia
NFO
Czas otwarcia dialogu
okna w notatniku
Otwieranie pliku VSI-Notepad [Ctrl+O]
Procesor, pamięć RAM i wejścia/wyjścia
ZHC*
Czas utworzyć wysoce skompresowany plik Zip
Lokalna kompresja
Skopiowano losowy plik .pst o rozmiarze 5 MB
puli zasobów
Procesor i wejścia/wyjścia
ZLC*
Czas utworzyć słabo skompresowany plik Zip
Lokalna kompresja
Skopiowano losowy plik .pst o rozmiarze 5 MB
puli zasobów
I / O
CPU
Obliczenia duże
losowa tablica danych
Tworzenie dużej tablicy
losowe dane, które zostaną wykorzystane w liczniku czasu wejścia/wyjścia (timera wejścia/wyjścia)
CPU
Podczas testowania początkowo obliczana jest podstawowa metryka VSIbase, która pokazuje prędkość, z jaką zadania są wykonywane bez obciążenia systemu. Na tej podstawie wyznaczany jest próg VSImax, który jest równy VSIbase + 1ms.
Wnioski na temat wydajności systemu wyciągane są na podstawie dwóch wskaźników: VSIbase, który określa szybkość systemu, oraz progu VSImax, który określa maksymalną liczbę użytkowników, których system może obsłużyć bez znaczącej degradacji.
Punkt odniesienia dla 300 pracowników wiedzy
Pracownicy wiedzy to użytkownicy, którzy regularnie obciążają pamięć, procesor i IO różnymi małymi szczytami. Oprogramowanie emuluje obciążenie pracą wymagających użytkowników biurowych, jakby ciągle o coś grzebali (PDF, Java, pakiet biurowy, przeglądanie zdjęć, 7-Zip). W miarę dodawania użytkowników od zera do 300, opóźnienie dla każdego z nich stopniowo wzrasta.
Dane statystyczne VSImax:
VSIbase = 986 ms, próg VSI nie został osiągnięty.
Statystyki obciążenia systemu pamięci masowej z monitorowania SimpliVity:
Przy tego typu obciążeniu system może wytrzymać zwiększone obciążenie praktycznie bez pogorszenia wydajności. Czas realizacji zadań użytkownika rośnie płynnie, czas reakcji systemu nie zmienia się podczas testów i wynosi do 3 ms w przypadku zapisu i do 1 ms w przypadku odczytu.
Wnioski: 300 użytkowników wiedzy pracuje na obecnym klastrze bez żadnych problemów i nie koliduje ze sobą, osiągając nadsubskrypcję pCPU/vCPU od 1 do 6. Ogólne opóźnienia rosną równomiernie wraz ze wzrostem obciążenia, ale ustalony limit nie został osiągnięty.
Test porównawczy 300 pracowników magazynu
Są to użytkownicy, którzy stale piszą i czytają w stosunku odpowiednio 30 do 70. Test ten przeprowadzono bardziej w celach eksperymentalnych. Dane statystyczne VSImax:
VSIbase = 1673, próg VSI osiągnięty na 240 użytkownikach.
Statystyki obciążenia systemu pamięci masowej z monitorowania SimpliVity:
Ten rodzaj obciążenia jest zasadniczo testem obciążeniowym systemu przechowywania. Po jego wykonaniu każdy użytkownik zapisuje na dysk wiele losowych plików o różnych rozmiarach. W tym przypadku można zauważyć, że w przypadku przekroczenia przez niektórych użytkowników określonego progu obciążenia, czas potrzebny na wykonanie zadań związanych z zapisywaniem plików wzrasta. Jednocześnie obciążenie systemu pamięci masowej, procesora i pamięci hostów nie zmienia się znacząco, dlatego obecnie nie można dokładnie określić, co jest przyczyną opóźnień.
Wnioski na temat wydajności systemu za pomocą tego testu można wyciągnąć jedynie w porównaniu z wynikami testów na innych systemach, ponieważ takie obciążenia są syntetyczne i nierealne. Jednak ogólnie test wypadł dobrze. Wszystko szło dobrze aż do 210 sesji, po czym zaczęły się dziwne reakcje, których nie można było śledzić nigdzie poza Loginem VSI.
300 pracowników energetyki
Są to użytkownicy, którzy kochają procesor, pamięć i wysokie IO. Ci „zaawansowani użytkownicy” regularnie wykonują złożone zadania w długich seriach, takie jak instalowanie nowego oprogramowania i rozpakowywanie dużych archiwów. Dane statystyczne VSImax:
VSIbase = 970, próg VSI nie został osiągnięty.
Statystyki obciążenia systemu pamięci masowej z monitorowania SimpliVity:
Podczas testów na jednym z węzłów systemu osiągnięto próg obciążenia procesora, jednak nie miało to istotnego wpływu na jego działanie:
W takim przypadku system może wytrzymać zwiększone obciążenie bez znaczącego pogorszenia wydajności. Czas realizacji zadań użytkownika rośnie płynnie, czas reakcji systemu nie zmienia się podczas testów i wynosi do 3 ms w przypadku zapisu i do 1 ms w przypadku odczytu.
Regularne testy nie wystarczyły klientowi i poszliśmy dalej: zwiększyliśmy charakterystykę maszyny wirtualnej (liczba procesorów vCPU w celu oceny wzrostu nadsubskrypcji i rozmiaru dysku) oraz dodaliśmy dodatkowe obciążenie.
Podczas przeprowadzania dodatkowych testów zastosowano następującą konfigurację stanowiska:
Wdrożono 300 wirtualnych desktopów w konfiguracji 4vCPU, 4GB RAM i 80GB HDD.
Konfiguracja jednej z maszyn testowych:
Maszyny wdrażane są w opcji Dedykowane – Pełna Kopia:
Benchmark 300 pracowników wiedzy z nadsubskrypcją 12
Dane statystyczne VSImax:
VSIbase = 921 ms, próg VSI nie został osiągnięty.
Statystyki obciążenia systemu pamięci masowej z monitorowania SimpliVity:
Uzyskane wyniki są podobne do wyników testowania poprzedniej konfiguracji maszyny wirtualnej.
300 pracowników energetyki z 12 nadsubskrypcjami
Dane statystyczne VSImax:
VSIbase = 933, próg VSI nie został osiągnięty.
Statystyki obciążenia systemu pamięci masowej z monitorowania SimpliVity:
Podczas tych testów osiągnięto również próg obciążenia procesora, ale nie miało to znaczącego wpływu na wydajność:
Uzyskane wyniki są podobne do wyników testowania poprzedniej konfiguracji.
Co się stanie, jeśli uruchomisz obciążenie na 10 godzin?
Zobaczmy teraz, czy wystąpi „efekt akumulacji” i przeprowadźmy testy przez 10 godzin z rzędu.
Długoterminowe badania i opis przekroju powinny mieć na celu to, że chcieliśmy sprawdzić, czy przy długotrwałym obciążeniu kratownicy nie wystąpią jakiekolwiek problemy z kratownicą.
Test porównawczy 300 pracowników wiedzy + 10 godzin
Dodatkowo przetestowano przypadek obciążenia 300 pracowników wiedzy, a następnie użytkownicy pracowali przez 10 godzin.
Dane statystyczne VSImax:
VSIbase = 919 ms, próg VSI nie został osiągnięty.
VSImax Szczegółowe dane statystyczne:
Wykres pokazuje, że w całym teście nie zaobserwowano żadnego pogorszenia wydajności.
Statystyki obciążenia systemu pamięci masowej z monitorowania SimpliVity:
Wydajność systemu pamięci masowej pozostaje taka sama przez cały czas trwania testu.
Dodatkowe badania z dodatkiem obciążenia syntetycznego
Klient poprosił o dodanie dzikiego obciążenia do dysku. W tym celu do systemu przechowywania danych na każdej z maszyn wirtualnych użytkownika dodano zadanie polegające na uruchomieniu syntetycznego obciążenia dysku, gdy użytkownik loguje się do systemu. Obciążenie zapewniło narzędzie fio, które pozwala ograniczyć obciążenie dysku liczbą IOPS. Na każdej maszynie uruchomiono zadanie uruchomienia dodatkowego obciążenia w ilości 22 IOPS 70%/30% Losowy odczyt/zapis.
Test porównawczy 300 pracowników wiedzy + 22 IOPS na użytkownika
We wstępnych testach stwierdzono, że fio powoduje znaczne obciążenie procesora na maszynach wirtualnych. Doprowadziło to do szybkiego przeciążenia procesora hostów i znacząco wpłynęło na działanie systemu jako całości.
Obciążenie procesora hosta:
Jednocześnie w naturalny sposób wzrosły opóźnienia w systemie przechowywania:
Brak mocy obliczeniowej stał się krytyczny w przypadku około 240 użytkowników:
Ze względu na uzyskane wyniki zdecydowano się przeprowadzić testy mniej obciążające procesor.
Test porównawczy 230 pracowników biurowych + 22 IOPS na użytkownika
Aby zmniejszyć obciążenie procesora, wybrano typ obciążenia Office Workers, a do każdej sesji dodano również 22 IOPS obciążenia syntetycznego.
Test ograniczono do 230 sesji, aby nie przekroczyć maksymalnego obciążenia procesora.
Test przeprowadzono na użytkownikach działających przez 10 godzin, aby sprawdzić stabilność systemu podczas długotrwałej pracy przy obciążeniu bliskim maksymalnemu.
Dane statystyczne VSImax:
VSIbase = 918 ms, próg VSI nie został osiągnięty.
VSImax Szczegółowe dane statystyczne:
Wykres pokazuje, że w całym teście nie zaobserwowano żadnego pogorszenia wydajności.
Statystyki obciążenia procesora:
Podczas wykonywania tego testu obciążenie procesora hostów było prawie maksymalne.
Statystyki obciążenia systemu pamięci masowej z monitorowania SimpliVity:
Wydajność systemu pamięci masowej pozostaje taka sama przez cały czas trwania testu.
Obciążenie systemu pamięci masowej podczas testu wyniosło około 6 IOPS w stosunku 500/60 (40 IOPS odczytu, 3 IOPS zapisu), co stanowi około 900 IOPS na stację roboczą.
Czas reakcji wynosił średnio 3 ms w przypadku zapisu i do 1 ms w przypadku odczytu.
Łączny
Podczas symulacji rzeczywistych obciążeń infrastruktury HPE SimpliVity uzyskano wyniki potwierdzające zdolność systemu do obsługi wirtualnych desktopów co najmniej 300 maszyn Full Clone na parze węzłów SimpliVity. Jednocześnie czas reakcji systemu magazynowania został utrzymany na optymalnym poziomie przez cały czas trwania testów.
Jesteśmy pod ogromnym wrażeniem podejścia do długich testów i porównywania rozwiązań przed wdrożeniem. Jeśli chcesz, możemy również przetestować wydajność Twoich obciążeń. W tym inne rozwiązania hiperkonwergentne. Wspomniany klient kończy obecnie równolegle testy innego rozwiązania. Jej obecna infrastruktura to po prostu flota komputerów, domena i oprogramowanie w każdym miejscu pracy. Przejście na VDI bez testów jest oczywiście dość trudne. W szczególności trudno jest zrozumieć rzeczywiste możliwości farmy VDI bez migracji do niej rzeczywistych użytkowników. A te testy pozwalają szybko ocenić realne możliwości konkretnego systemu, bez konieczności angażowania zwykłych użytkowników. Stąd wzięło się to badanie.
Drugie ważne podejście polega na tym, że klient od razu zobowiązał się do odpowiedniego skalowania. Tutaj możesz dokupić dodatkowy serwer i dodać farmę np. na 100 użytkowników, wszystko jest przewidywalne w cenie użytkownika. Na przykład, gdy będą musieli dodać 300 dodatkowych użytkowników, będą wiedzieć, że potrzebują dwóch serwerów w już zdefiniowanej konfiguracji, zamiast ponownie rozważać modernizację całej infrastruktury.
Możliwości federacji HPE SimpliVity są interesujące. Firma jest oddzielona geograficznie, dlatego warto zainstalować własny, oddzielny sprzęt VDI w odległym biurze. W federacji SimpliVity każda maszyna wirtualna jest replikowana według harmonogramu z możliwością bardzo szybkiej replikacji pomiędzy geograficznie odległymi klastrami i bez obciążenia kanału - jest to wbudowana kopia zapasowa na bardzo dobrym poziomie. Podczas replikacji maszyn wirtualnych pomiędzy lokalizacjami kanał jest wykorzystywany w możliwie minimalnym stopniu, co umożliwia budowanie bardzo interesujących architektur DR w obecności jednego centrum kontroli i kilku zdecentralizowanych lokalizacji pamięci masowej.
Wszystko to razem pozwala na bardzo szczegółową ocenę strony finansowej, nałożenie kosztów VDI na plany rozwoju firmy oraz zrozumienie, jak szybko rozwiązanie się zwróci i jak będzie działać. Bo każde VDI to rozwiązanie, które docelowo pozwala zaoszczędzić mnóstwo zasobów, ale jednocześnie najprawdopodobniej bez opłacalnej możliwości jego wymiany w ciągu 5-7 lat użytkowania.
Ogólnie rzecz biorąc, jeśli masz jakieś pytania, które nie wymagają komentarza, napisz do mnie e-mailem [email chroniony].
Źródło: www.habr.com