Zákazník chtěl VDI. Velmi se zajímal o kombinaci SimpliVity + VDI Citrix Virtual Desktop. Pro všechny operátory, zaměstnance kanceláří ve městech atd. Tam je na prvním kole migrace pět tisíc uživatelů, a proto trvali na zátěžovém testování. VDI může začít zpomalovat, může se klidně zastavit — a ne vždy se to děje kvůli problémům s kanálem. Zakoupili jsme velmi výkonný testovací balíček speciálně pro VDI a zatěžovali jsme infrastrukturu, dokud se nevyčerpala na discích a procesoru.
Takže budeme potřebovat plastovou láhev, software LoginVSI pro pokročilé testy VDI. Ten máme s licencemi pro 300 uživatelů. Poté jsme vzali hardware HPE SimpliVity 380 vhodný pro úkol maximální hustoty uživatelů na jeden server, vytvořili jsme virtuální stroje s dobrou přerozdělením, nainstalovali jsme na ně kancelářský software na Win10 a začali testovat.
Začínáme!
Systém
Dva uzly (servery) HPE SimpliVity 380 Gen10. Na každém:
- 2 x Intel Xeon Platinum 8170 26c 2.1Ghz.
- Operační paměť: 768GB, 12 x 64GB LRDIMMs DDR4 2666MHz.
- Hlavní diskový řadič: HPE Smart Array P816i-a SR Gen10.
- Pevné disky: 9 x 1.92 TB SATA 6Gb/s SSD (v konfiguraci RAID6 7+2, tj. to je model Medium podle HPE SimpliVity).
- Síťové karty: 4 x 1Gb Eth (uživatelská data), 2 x 10Gb Eth (backend SimpliVity a vMotion).
- Speciální vestavěné FPGA karty v každém uzlu pro deduplikaci/kompresi.
Uzly jsou spojeny mezi sebou 10Gb Ethernet interkonnectem přímo bez externího přepínače, který se používá jako backend SimpliVity a pro přenos dat virtuálních strojů po NFS. Data virtuálních strojů v clusteru jsou vždy zrcadlena mezi dvěma uzly.
Uzly jsou spojeny do clusteru Vmware vSphere řízeného vCentrem.
Pro provedení testování byly nasazeny řadič domény a broker připojení Citrix. Řadič domény, broker a vCenter byly umístěny na samostatném clusteru.
Jako testovací infrastruktura byly nasazeny 300 virtuálních pracovních stanic v konfiguraci Dedicated – Full Copy, tj. každá pracovní stanice představuje úplnou kopii originálního obrazu virtuálního stroje a uchovává všechny změny provedené uživateli.
Každý virtuální stroj má 2vCPU a 4GB RAM:
Na virtuální stroje bylo nainstalováno následující software, požadovaný pro provedení testování:
- Windows 10 (64-bit), verze 1809.
- Adobe Reader XI.
- Citrix Virtual Delivery Agent 1811.1.
- Doro PDF 1.82.
- Java 7 Update 13.
- Microsoft Office Professional Plus 2016.
Mezi uzly probíhá synchronní replikace. Každý blok dat v clusteru má dvě kopie. To znamená, že nyní je kompletní soubor dat na každém z uzlů. U clusteru se třemi a více uzly jsou kopie bloků na dvou různých místech. Při vytváření nového VM se vytvoří dodatečná kopie na jednom z uzlů clusteru. Pokud jeden uzel selže, všechny VM, které na něm byly dříve spuštěny, se automaticky restartují na ostatních uzlech, kde mají své repliky. Pokud uzel selže na delší dobu, začne postupné obnovení redundancy a cluster se vrací k rezervaci N+1.
Vyvažování a ukládání dat probíhá na úrovni softwarového úložiště samotného SimpliVity.
Virtuální stroje spouští virtualizační cluster, který je také umisťuje na softwarové úložiště. Pracovní stanice byly převzaty podle standardní šablony: na test dorazily pracovní stanice financistů a operátorů (to jsou dvě odlišné šablony).
Testování
Pro provedení testování byl použit testovací komplex softwaru LoginVSI 4.1. Komplex LoginVSI, skládající se z řídicího serveru a 12 strojů pro testovací připojení, byl nasazen na samostatném fyzickém hostiteli.
Testování probíhalo ve třech režimech:
Režim Benchmark — varianty zátěže 300 Knowledge workers a 300 Storage workers.
Standardní režim — varianta zátěže 300 Power workers.
Aby byla možná práce Power workers a zvýšila se rozmanitost zátěže, byla do komplexu LoginVSI přidána knihovna dodatečných souborů Power Library. Pro zajištění opakovatelnosti výsledků byly všechny nastavení testovacího standu ponechány jako Default.
Testy Knowledge a Power workers imituje skutečné zatížení uživatelů pracujících na virtuálních pracovních stanicích.
Test Storage workers byl vytvořen speciálně pro testování systémů ukládání dat, je vzdálen od skutečných zátěží a většinou spočívá v práci uživatele s velkým množstvím souborů různých velikostí.
Během testování se uživatelé přihlašují na pracovní stanice po dobu 48 minut, přičemž přibližně každý 10. sekund se přihlašuje jeden uživatel.
Výsledky
Hlavním výsledkem testování LoginVSI je metrika VSImax, která se sestavuje z doby trvání různých úkolů prováděných uživateli. Například: doba otevření souboru v poznámkovém bloku, doba komprese souboru v 7-Zip atd.
Podrobné popisy výpočtu metrik jsou k dispozici v oficiální dokumentaci k .
Jinými slovy, LoginVSI simuluje typový zátěový vzor, napodobující činnosti uživatele v kancelářském balíku při čtení PDF a podobně, a měří různé latence. Existuje kritická úroveň latence, při které "všechno zpomaluje, práce je nemožná"; do dosažení této hranice se považuje, že se maximální počet uživatelů nedosáhne. Pokud je doba reakce na 1 000 ms rychlejší než tato kritická hranice "všechno zpomaluje", je považováno, že systém pracuje normálně a můžeme přidávat další uživatele.
Zde jsou hlavní metriky:
Metrika
Prováděné akce
Podrobné popis
Zatěžované komponenty
NSLD
Doba otevření textového
souboru o velikosti 1 500 KB
Spouští se Poznámkový blok a
otevírá náhodný dokument o velikosti 1 500 KB, který byl zkopírován z poolu
zdrojů
CPU a I/O
NFO
Doba otevření dialogového
okna v Poznámkovém bloku
Otevření souboru VSI-Notepad [Ctrl+O]
CPU, RAM a I/O
ZHC*
Doba vytvoření Zip-souboru s vysokým kompresním poměrem
Kompresní lokální
náhodný soubor ve formátu .pst o velikosti 5 MB, který byl zkopírován z
poolu zdrojů
CPU a I/O
ZLC*
Doba vytvoření Zip-souboru s nízkým kompresním poměrem
Kompresní lokální
náhodný soubor ve formátu .pst o velikosti 5 MB, který byl zkopírován z
poolu zdrojů
I/O
CPU
Výpočet velkého
pole náhodných dat
Vytvoření velkého pole
náhodných dat, které budou použity v I/O časovači
CPU
Při testování se nejprve počítá základní metrika VSIbase, která ukazuje rychlost plnění úkolů bez zátěže na systém. Na jejím základě se určuje VSImax Threshold, který je roven VSIbase + 1 000 ms.
Závěry o výkonnosti systému se dělají na základě dvou metrik: VSIbase, která určuje rychlost práce systému, a VSImax threshold, která určuje maximální počet uživatelů, které systém zvládne bez významné degradace.
300 benchmark pro znalostní pracovníky
Znalostní pracovníci jsou uživatelé, kteří pravidelně zatěžují paměť, procesor a I/O malými špičkami. Software simuluje zátěž od náročných kancelářských uživatelů, jako by neustále něco klikali (PDF, Java, kancelářský balík, prohlížení fotografií, 7-Zip). Se zvyšujícím se počtem uživatelů od nuly do 300 latence u každého plynule roste.
Statistiky VSImax:
VSIbase = 986 ms, VSI Threshold nebyl dosažen.
Statistika zátěže na úložišti z monitorování SimpliVity:
Při tomto typu zátěže systém snáší zvýšení zatížení prakticky bez degradace výkonu. Doba provádění uživatelských úloh se zvyšuje plynule, doba odezvy systému zůstává během testování nezměněná a dosahuje až 3 ms při zápisu a až 1 ms při čtení.
Výstup: 300 uživatelů knowledge bez jakýchkoli problémů pracuje na aktuálním clusteru a navzájem si nepřekáží, dosahujíc předplatného pCPU/vCPU 1 ku 6. Celkové zpoždění při zvyšování zatížení se rovnoměrně zvyšuje, ale stanovený limit nebyl dosažen.
300 benchmark pracovníků Storage
To jsou uživatelé, kteří neustále zapisují a čtou v poměru 30 ku 70. Tento test byl proveden spíše pro experiment. Statistiky VSImax:
VSIbase = 1673, VSI Threshold byl dosažen na 240 uživatelích.
Statistika zátěže na úložišti z monitorování SimpliVity:
Tento typ zátěže je v podstatě stresovým testem systému úložiště. Při jeho provádění každý uživatel zapisuje na disk množství náhodných souborů různých velikostí. V tomto případě je vidět, že po překročení určitého prahu zatížení se části uživatelů zvyšuje doba provádění úloh na zápis souborů. Zatímco zátěž na systém úložiště, procesor a paměť hostitelů se podstatně nemění, nelze přesně určit, čím jsou způsobena zpoždění.
Závěry o výkonu systému pomocí tohoto testu lze dělat pouze v porovnání s výsledky testu na jiných systémech, protože takové zátěže jsou syntetické a nerealistické. Nicméně, celkově test proběhl docela dobře. Až do 210 relací vše probíhalo dobře, pak začala nevysvětlitelná zpoždění, která nebyla sledována nikde jinde kromě Login VSI.
300 Power pracovníků
To jsou uživatelé, kteří mají rádi procesor, paměť a vysokou IO. Tito "pokročilí uživatelé" pravidelně spouštějí složité úlohy s dlouhými špičkami jako je instalace nového software a rozbalování velkých archivů. Statistiky VSImax:
VSIbase = 970, VSI Threshold nebyl dosažen.
Statistika zátěže na úložišti z monitorování SimpliVity:
Během testování byl dosažen prah zatížení procesorů na jednom z uzlů systému, ale to nemělo zásadní vliv na jeho funkci:
V tomto případě systém zvládá zvýšení zátěže také bez zásadní degradace výkonu. Doba provádění uživatelských úloh se zvyšuje plynule, doba odezvy systému během testování zůstává nezměněna a činí až 3 ms pro zápis a až 1 ms pro čtení.
Běžné testy pro zákazníka nebyly dostatečné, a tak jsme šli dál: zvýšili jsme charakteristiky VM (počet vCPU, abychom posoudili zvýšení přetížení a velikost disku) a přidali dodatečnou zátěž.
Při provádění dalších testů byla použita následující konfigurace stánku:
Nasazeno 300 virtuálních pracovních stanic v konfiguraci 4vCPU, 4GB RAM, 80GB HDD.
Konfigurace jednoho z testovacích strojů:
Stroje byly nasazeny ve variantě Dedicated – Full Copy:
300 benchmarků Knowledge workers s přetížením 12
Statistiky VSImax:
VSIbase = 921 ms, prahový VSI nebyl dosažen.
Statistika zátěže na úložišti z monitorování SimpliVity:
Získané výsledky jsou podobné testování předchozí konfigurace VM.
300 benchmarků Power workers s přetížením 12
Statistiky VSImax:
VSIbase = 933, prahový VSI nebyl dosažen.
Statistika zátěže na úložišti z monitorování SimpliVity:
Při tomto testování byl také dosažen prah zátěže procesorů, ale to nemělo zásadní vliv na výkon:
Získané výsledky jsou podobné testování předchozí konfigurace.
Co se stane, když zatížíme systém po dobu 10 hodin?
Nyní se podíváme, zda bude „efekt akumulace“, a spustíme testy na 10 hodin nepřetržitě.
Dlouhé testy a popis kapitoly by měly být zaměřeny na to, co jsme chtěli ověřit, zda dojde k nějakým problémům s farmou při dlouhodobém zatížení.
300 benchmarků Knowledge workers + 10 hodin
Navíc bylo provedeno testování varianty zátěže 300 knowledge workers s následnou činností uživatelů po dobu 10 hodin.
Statistiky VSImax:
VSIbase = 919 ms, prahový VSI nebyl dosažen.
Data statistiky VSImax Detailed:
Na grafu je vidět, že během celého testu nedocházelo k žádné degradaci výkonu.
Statistika zátěže na úložišti z monitorování SimpliVity:
Výkon systému úložiště zůstává na jedné úrovni po celou dobu testu.
Další testování s přidáním syntetické zátěže
Zákazník požádal o přidání zátěže na disk. K tomu bylo do systému úložišť v každé z virtuálních strojů uživatelů přidáno úkol na zahájení syntetické zátěže na disk při přihlášení uživatele do systému. Zátěž byla zajištěna utilitou fio, která umožňuje omezit zátěž na disk podle počtu IOPS. V každém stroji byl spuštěn úkol na spuštění dodatečné zátěže o velikosti 22 IOPS 70 %/30 % Random Read/Write.
300 benchmark pro znalostní pracovníky + 22 IOPS na uživatele
Při prvotním testování bylo zjištěno, že fio vytváří významnou dodatečnou zátěž na procesor virtuálních strojů. To vedlo k rychlému přetížení hostitelů CPU a výrazně ovlivnilo funkci systému jako celku.
Zátěž na CPU hostitelů:
Zpoždění systému úložišť se při tom také logicky zvýšila:
Nedostatek výpočetního výkonu se stal kritickým přibližně při 240 uživatelích:
Na základě získaných výsledků bylo rozhodnuto provést testování, které méně zatěžuje CPU.
230 benchmark pro kancelářské pracovníky + 22 IOPS na uživatele
Pro snížení zátěže na CPU byl vybrán typ zátěže kancelářských pracovníků, na každou seanci bylo také přidáno 22 IOPS syntetické zátěže.
Test byl omezen na 230 seancí, aby nebyla překročena maximální zátěž na CPU.
Test byl spuštěn s následnou prací uživatelů po dobu 10 hodin pro ověření stability systému při dlouhé práci na zátěži blízké maximální.
Statistiky VSImax:
VSIbase = 918 ms, VSI Threshold nebyl překročen.
Data statistiky VSImax Detailed:
Na grafu je vidět, že během celého testu nedocházelo k žádné degradaci výkonu.
Údaje o statistice zátěže na CPU:
Při provádění tohoto testu byla zátěž na CPU hostitelů téměř maximální.
Statistika zátěže na úložišti z monitorování SimpliVity:
Výkon systému úložiště zůstává na jedné úrovni po celou dobu testu.
Zátěž na systém úložišť během testu byla přibližně 6 500 IOPS v poměru 60/40 (3 900 IOPS - na čtení, 2 600 IOPS - na zápis), což představuje přibližně 28 IOPS na jednu pracovní stanici.
Průměrná doba odezvy byla 3 ms na zápis a až 1 ms - na čtení.
Výsledek
Při modelování skutečných zátěží na infrastruktuře HPE SimpliVity byly získány výsledky, které potvrzují schopnost systému zajistit provoz virtuálních pracovních stolů v počtu nejméně 300 Full Clone-strojů na dvou uzlech SimpliVity. Přitom doba odezvy systému úložišť zůstávala na optimální úrovni po celou dobu testování.
Velmi nás oslovuje přístup k dlouhým testům a srovnání řešení před zavedením. Můžeme otestovat výkon i pro vaše zatížení, pokud chcete. Včetně jiných hyperkonvergovaných řešení. Zmíněný zákazník právě dokončuje testy na jiném řešení paralelně. Jeho aktuální infrastruktura je prostě park PC, domén a softwaru na každém pracovním místě. Přecházet na VDI bez testů je samozřejmě docela složité. Obzvlášť je obtížné pochopit skutečné možnosti VDI farmy, aniž bychom na ni přemigrovali skutečné uživatele. A tyto testy umožňují rychle posoudit skutečné možnosti daného systému bez nutnosti zapojení běžných uživatelů. Odtud vzniklo takové zkoumání.
Druhý důležitý přístup — zákazník se okamžitě zaměřil na správné škálování. Zde je možné dokoupit server a přidat farmu, například pro 100 uživatelů, vše je předvídatelné podle ceny na uživatele. Například když budou potřebovat přidat dalších 300 uživatelů, budou vědět, že potřebují dva servery v už definované konfiguraci, a ne přehodnocovat možnosti modernizace své infrastruktury jako celku.
Zajímavé jsou možnosti federace HPE SimpliVity. Byznys je geograficky rozdělen, proto má smysl stavět do vzdálené kanceláře svou vlastní VDI mašinu. V federaci SimpliVity je každá virtuálka replikována podle plánu s možností provádět velmi rychlé replikace mezi geograficky vzdálenými clustery bez zatížení kanálu — je to vestavěná záloha velmi dobré úrovně. Při replikaci VM mezi lokalitami je kanál zapojen tak minimálně, jak to jen jde, a to umožňuje budovat velmi zajímavé architektury DR s jedním centrem řízení a spoustou decentralizovaných úložišť.
To vše dohromady umožňuje velmi podrobně posoudit i finanční stránku a promítnout náklady na VDI na plány růstu společnosti a pochopit, jak rychle se řešení zaplatí a jak bude fungovat. Protože jakýkoli VDI je řešení, které nakonec šetří spoustu zdrojů, ale pravděpodobně jde těžko ekonomicky výhodně vyměnit během 5–7 let používání.
Pokud máte další dotazy, které nejsou určeny ke komentářům, napište mi na e-mail mk@croc.ru.
Zdroj: habr.com
