A megrendelő VDI-t szeretett volna. Nagyon figyelte a SimpliVity + Citrix Virtual Desktop párosítást. Minden operátornak, irodai alkalmazottnak a városokban és így tovább. Az első migrációs hullámban ötezer felhasználó van, ezért ragaszkodtak a terhelési teszteléshez. A VDI akadozhat, de simán le is fékezhet — és ez nem mindig a sávszélességgel kapcsolatos problémák miatt történik. Kifejezetten VDI-re vásároltunk egy nagyon erős tesztcsomagot, és terheltük az infrastruktúrát, amíg le nem állt a lemezek és a processzor miatt.
Tehát szükségünk lesz egy műanyag palackra, a LoginVSI szoftverre a VDI bonyolult tesztjeihez. Nekünk van belőle 300 felhasználóra licenszelt verzió. Aztán vettünk HPE SimpliVity 380 hardvert, amely a felhasználók maximális sűrűségének elérésére alkalmas konfigurációval rendelkezik, virtuális gépeket készítettünk jó újraintegrálással, telepítettük rájuk az irodai szoftvert Win10 alatt, és elkezdtük a tesztelést.
Kezdjük!
Rendszer
Két HPE SimpliVity 380 Gen10 csomópont (szerver):
- 2 x Intel Xeon Platinum 8170 26c 2.1Ghz.
- RAM: 768GB, 12 x 64GB LRDIMMs DDR4 2666MHz.
- Fő lemezkontroller: HPE Smart Array P816i-a SR Gen10.
- Merevlemezek: 9 x 1.92 TB SATA 6Gb/s SSD (RAID6 7+2 konfigurációval, azaz ez a Medium modell az HPE SimpliVity kifejezésében).
- Hálózati kártyák: 4 x 1Gb Eth (felhasználói adatok), 2 x 10Gb Eth (SimpliVity backend és vMotion).
- Speciális beépített FPGA kártyák minden csomópontban deduplikáció/kompresszió céljából.
A csomópontok közvetlen 10Gb Ethernet interkonnektálással kapcsolódnak egymáshoz külső switch nélkül, amelyet SimpliVity backend-ként és a virtuális gépek NFS-en keresztüli adatátvitelére használnak. A klaszterben lévő virtuális gépek adatai mindig tükröződnek a két csomópont között.
A csomópontok Vmware vSphere klaszterbe vannak integrálva, vCenter irányításával.
A teszteléshez domain-vezérlőt és Citrix kapcsolati brokert állítottunk fel. A domain-vezérlő, broker és vCenter külön klaszterre került.
Tesztinfrastruktúraként 300 virtuális munkaasztalt állítottunk be Dedicated – Full Copy konfigurációban, azaz minden munkaasztal az eredeti virtuális gép teljes másolatát jelenti, és megőrzi a felhasználók által végzett módosításokat.
Minden virtuális gépnek 2vCPU-ja és 4GB RAM-ja van:
A következő szoftvereket telepítettük a virtuális gépekre, amelyek a teszteléshez szükségesek:
- Windows 10 (64-bit), 1809-es verzió.
- Adobe Reader XI.
- Citrix Virtual Delivery Agent 1811.1.
- Doro PDF 1.82.
- Java 7 Update 13.
- Microsoft Office Professional Plus 2016.
A csomópontok között szinkron replikáció zajlik. Minden adatblokkhoz a klaszterben két másolat tartozik. Ezért most minden csomóponton teljes adatállomány található. Három vagy több csomópontos klaszter esetén a blokkok másolatai két különböző helyen vannak. Amikor új VM-et hozunk létre, egy további másolat készül a klaszter egyik csomópontján. Ha egy csomópont meghibásodik, az azon korábban futó összes VM automatikusan újraindul a többi csomóponton, ahol van másolatuk. Ha a csomópont hosszabb időre meghibásodik, megkezdődik a redundancia fokozatos helyreállítása, és a klaszter ismét N+1 rezerválásra tér vissza.
Az egyensúlyozás és az adatok tárolása a SimpliVity szoftveres tárolójának szintjén történik.
A virtuális gépek egy virtualizációs klasztert indítanak, amely elhelyezi őket a szoftveres tárolón. A munkahelyi asztalok tipikus sablon szerint készültek: a teszt során pénzügyi és operatív asztalokat használtunk (ez két külön sablon).
Tesztelés
A teszteléshez a LoginVSI 4.1 szoftver tesztelő komplexumot használták. A LoginVSI komplexum irányító szerverből és 12 tesztcsatlakozásra szolgáló gépből állt, amelyet egy külön fizikai hoszton telepítettek.
A tesztelés három módban zajlott:
Benchmark mód - a terhelési variációk: 300 Knowledge workers és 300 Storage workers.
Alapértelmezett mód - a terhelési variáció: 300 Power workers.
A Power workers munkavégzésének lehetővé tétele és a terhelés sokféleségének növelése érdekében a LoginVSI komplexumhoz Power Library néven egy kiegészítő fájlgyűjteményt adtak hozzá. Az eredmények megismételhetősége érdekében a tesztkörnyezet összes beállítását alapértelmezett értéken hagyták.
A Knowledge és Power workers tesztek a virtuális munkaállomásokon dolgozó felhasználók valós terhelését imitálják.
A Storage workers tesztet kifejezetten adattároló rendszerek tesztelésére tervezték, távol áll a valós terhelésektől, és nagyrészt a felhasználó munkáját jelenti sokféle méretű fájllal.
A tesztelés során a felhasználók körülbelül 48 percig csatlakoznak a munkaállomásokhoz, körülbelül 10 másodpercenként egy felhasználóval.
Eredmények
A tesztelés fő eredménye a LoginVSI esetében a VSImax metrika, amely a felhasználó által végrehajtott különböző feladatok végrehajtási idejéből áll össze. Például: a fájl megnyitásának ideje a Jegyzettömbben, a fájl tömörítési ideje a 7-Zip programban stb.
A metrikák számlálásának részletes leírása a következő hivatalos dokumentációban érhető el .
Más szóval, a LoginVSI egy tipikus terhelési mintát ismétel, szimulálva a felhasználók tevékenységeit, például irodai csomagok használatát, PDF fájlok olvasását és egyebeket, és különböző késleltetéseket mér. Van egy kritikus késleltetési szint, amikor "minden megáll, dolgozni lehetetlen"), ameddig elérve azt, hogy a maximális felhasználószám még nem teljesült. Ha a válaszidő 1000 ms-nál gyorsabb, mint a "minden megáll" állapot, akkor azt az állapotot normálisnak tekintjük, és további felhasználók adhatók hozzá.
Íme a főbb metrikák:
Metrika
Végrehajtott tevékenységek
Részletes leírás
Terhelt összetevők
NSLD
1 500 Kbyte méretű szöveges fájl megnyitási ideje
A Jegyzettömb elindul és megnyit egy 1 500 Kbyte méretű véletlenszerű dokumentumot, amely a forráskészletből lett átmásolva
erőforrások
CPU és I/O
NFO
A Jegyzettömb megnyitásához szükséges párbeszédablak nyitási ideje
A VSI-Notepad fájl megnyitása [Ctrl+O]
CPU, RAM és I/O
ZHC*
Erősen tömörített Zip-fájl létrehozásának ideje
Egy helyi 5MB méretű véletlenszerű .pst fájl tömörítése, amely a forráskészletből lett átmásolva
ZLC*
Gyengén tömörített Zip-fájl létrehozásának ideje
I/O
Nagy véletlenszámú adathalmaz kiszámítása
Nagy véletlenszámú adathalmazon alapuló adatsor létrehozása, amely az I/O időzítőben lesz felhasználva
A Jegyzettömb megnyitásához szükséges párbeszédablak nyitási ideje
A tesztelés során kezdetben a VSIbase alapmetrika számítódik ki, amely megmutatja a feladatok elvégzésének sebességét a rendszer terhelése nélkül. Ezen alapul meghatározzák a VSImax küszöbértéket, amely egyenlő a VSIbase + 1000 ms-tal.
A rendszer teljesítményéről a két metrika, a VSIbase, amely a rendszer gyorsaságát határozza meg, és a VSImax küszöbérték, amely a rendszer által elviselhető maximális felhasználószámot határozza meg, alapján vonnak le következtetéseket.
I/O
Nagy véletlenszámú adathalmaz kiszámítása
Nagy véletlenszámú adathalmazon alapuló adatsor létrehozása, amely az I/O időzítőben lesz felhasználva
300 tudásmunkás referenciaérték
CPU
300 Knowledge workers benchmark
300 Knowledge workers benchmark
300 Knowledge workers benchmark
300 Knowledge workers benchmark
CPU
300 Knowledge workers benchmark
300 Knowledge workers benchmark
300 Knowledge workers benchmark
A tudásalapú munkavállalók olyan felhasználók, akik rendszeresen terhelik a memóriát, a processzort és az IO-t különféle apró csúcsokkal. A szoftver úgy szimulálja a terhelést, mintha a követelményes irodai felhasználók folyamatosan kattintgatnának (PDF, Java, irodai programcsomag, fotók megtekintése, 7-Zip). A felhasználók számának növekedésével nulláról 300-ig mindenki késleltetése fokozatosan nő.
A VSImax statisztikái:
VSIbase = 986ms, a VSI küszöböt nem értük el.
A SimpliVity monitorozásából származó tárolórendszer terhelési statisztikája:
Ezen terheléstípus mellett a rendszer a terhelés növekedését szinte teljesítménycsökkenés nélkül bírja el. A felhasználói feladatok végrehajtási ideje fokozatosan nő, a rendszer válaszideje a tesztelés alatt nem változik, és legfeljebb 3ms írásra és 1ms olvasásra.
Következtetés: 300 tudásalapú felhasználó problémamentesen dolgozik az aktuális klaszterben és nem zavarják egymást, elérve az 1:6 pCPU/vCPU túlfoglalást. A terhelés növekedésével a késleltetések fokozatosan növekednek, de a megállapított határértéket nem értük el.
300 tároló munkavállaló benchmark
Ezek olyan felhasználók, akik folyamatosan írnak és olvasnak 30:70 arányban. Ezt a tesztet inkább kísérletképpen végezték. A VSImax statisztikák:
VSIbase = 1673, a VSI küszöböt 240 felhasználónál értük el.
A SimpliVity monitorozásából származó tárolórendszer terhelési statisztikája:
Ez a terheléstípus lényegében a tárolórendszer stressztesztje. E teszt végrehajtása során minden felhasználó sok véletlenszerű fájlt különböző méretekben ír a lemezre. Ekkor látható, hogy a terhelési küszöb átlépésekor egyes felhasználóknál megnő a fájlok írásának végrehajtási ideje. Ugyanakkor a tárolórendszer, a processzor és a hostok memória terhelése lényegesen nem változik, ezért jelenleg nem lehet pontosan megmondani, hogy a késleltetések mivel függenek össze.
A rendszer teljesítményéről e teszt alapján csak más rendszerek tesztjeinek eredményeivel való összehasonlítás fényében lehet következtetni, mivel ezek a terhelések szintetikusak és nem reálisak. Ennek ellenére összességében a teszt jól teljesült. 210 munkamenetig minden rendben zajlott, ezután kezdődtek a megmagyarázhatatlan válaszok, amelyeket azonban sehol, csak a Login VSI-nél nem követtek nyomon.
300 Power munkavállaló
Ezek azok a felhasználók, akik szeretik a processzort, a memóriát és a magas IO-t. Ezek az „előrehaladott felhasználók” rendszeresen futtatnak bonyolult feladatokat, hosszú csúcsokkal, például új szoftverek telepítésével és nagy archívumok kibővítésével. A VSImax statisztikai adatai:
VSIbase = 970, a VSI küszöbértékét nem értük el.
A SimpliVity monitorozásából származó tárolórendszer terhelési statisztikája:
A tesztelés során a rendszer egy csomópontján elértük a processzorok terhelési küszöbértékét, de ennek nem volt jelentős hatása a működésére:
Ebben az esetben a rendszer a terhelés növekedését is képes elviselni, jelentős teljesítményromlás nélkül. A felhasználói feladatok végrehajtási ideje fokozatosan nő, a rendszer válaszideje a tesztelés során nem változik, és legfeljebb 3 ms íráskor és 1 ms olvasáskor.
A szokásos tesztek nem voltak elegendőek az ügyfél számára, ezért tovább léptünk: növeltük a VM jellemzőit (vCPU szám, hogy felmérjük a túlszolgáltatást és a lemezméretet) és extra terhelést adtunk hozzá.
A további tesztek elvégzése során a következő tesztkörnyezetet használtuk:
300 virtuális munkahelyet állítottunk be 4vCPU, 4GB RAM, 80GB HDD konfigurációban.
Az egyik tesztgép konfigurációja:
A gépek Dedicated – Full Copy változatban vannak telepítve:
300 Knowledge workers benchmark 12-es túlszolgáltatással
A VSImax statisztikái:
VSIbase = 921 ms, a VSI küszöbértékét nem értük el.
A SimpliVity monitorozásából származó tárolórendszer terhelési statisztikája:
Az eredmények hasonlóak a korábbi VM konfiguráció teszteléséhez.
300 Power workers 12-es túlszolgáltatással
A VSImax statisztikái:
VSIbase = 933, a VSI küszöbértékét nem értük el.
A SimpliVity monitorozásából származó tárolórendszer terhelési statisztikája:
A jelen tesztelés során szintén elértük a processzorok terhelési küszöbértékét, de ennek nem volt jelentős hatása a teljesítményre:
Az eredmények hasonlóak a korábbi konfiguráció teszteléséhez.
Mi történik, ha 10 órás terhelést futtatunk?
Most megnézzük, hogy lesz-e „felhalmozódási hatás”, és 10 órán át folyamatosan futtatjuk a teszteket.
A hosszú teszteknek és a szakasz leírásának azt kell céloznia, hogy ellenőrizzük, lesznek-e problémák a farmnál a hosszú ideig tartó terhelés alatt.
300 Knowledge workers benchmark + 10 óra
Ezenkívül teszteltük a 300 knowledge workers terhelésének változatát, a felhasználók további 10 órás munkavégzésével.
A VSImax statisztikái:
VSIbase = 919 ms, a VSI küszöbértékét nem értük el.
A VSImax részletes statisztikai adatai:
A grafikon alapján látható, hogy a teszt teljes időtartama alatt nem tapasztalható teljesítményromlás.
A SimpliVity monitorozásából származó tárolórendszer terhelési statisztikája:
A tárolórendszer teljesítménye a teszt során változatlan maradt.
További tesztelés szintetikus terhelés hozzáadásával
Az ügyfél kérte, hogy terhelést adjunk hozzá a lemezhez. Ennek érdekében a tárolórendszerhez minden egyes felhasználói virtuális gépről indítottunk egy feladatot, amely szintetikus terhelést generált a lemezen a felhasználó belépésekor. A terhelést a fio segédprogram biztosította, amely lehetővé teszi a lemezen végzett IOPS terheléskorlátozást. Minden gépen 22 IOPS terheléssel indítottuk a kiegészítő terhelés feladatát, 70%/30% arányban végezve véletlenszerű olvasást/írást.
300 tudásalapú dolgozó benchmark + 22 IOPS felhasználónként
Az első tesztelés során kiderült, hogy a fio jelentős extra terhelést generál a virtuális gépek CPU-ján. Ez gyors CPU-túlterheléshez vezetett, ami nagymértékben befolyásolta a rendszer működését.
A hotelek CPU terhelése:
A tárolórendszer késése is értelemszerűen megnövekedett:
A számítási kapacitás hiánya körülbelül 240 felhasználónál kritikus szintre emelkedett:
A kapott eredmények hatására úgy döntöttek, hogy olyan tesztelést végeznek, amely kevésbé terheli a CPU-t.
230 irodai dolgozó benchmark + 22 IOPS felhasználónként
A CPU terhelésének csökkentése érdekében az irodai dolgozók terheléstípust választottak, amelyhez minden munkamenethez 22 IOPS szintetikus terhelés is hozzá lett adva.
A tesztet 230 munkamenetre korlátozták, hogy elkerüljék a CPU maximális terhelésének túllépését.
A tesztet a felhasználók további 10 órás munkájával indították el a rendszer stabilitásának ellenőrzésére, közel maximális terhelés mellett.
A VSImax statisztikái:
VSIbase = 918 ms, VSI küszöböt nem értük el.
A VSImax részletes statisztikai adatai:
A grafikon alapján látható, hogy a teszt teljes időtartama alatt nem tapasztalható teljesítményromlás.
Statisztikai adatok a CPU terheléséről:
A teszt végrehajtása során a hotelek CPU terhelése gyakorlatilag maximális volt.
A SimpliVity monitorozásából származó tárolórendszer terhelési statisztikája:
A tárolórendszer teljesítménye a teszt során változatlan maradt.
A tárolórendszer terhelése a teszt során körülbelül 6 500 IOPS volt, 60/40 arányban (3 900 IOPS olvasás, 2 600 IOPS írás), ami körülbelül 28 IOPS-t jelent munkaterületenként.
Az átlagos válaszidő 3 ms volt írásnál és akár 1 ms olvasásnál.
Result
A valós terhelések modellezésekor az HPE SimpliVity infrastruktúráján elért eredmények megerősítették a rendszer képességét, hogy legalább 300 Full Clone gépet üzemeltessen SimpliVity csomópárokon. Ezzel párhuzamosan a tárolórendszer válaszideje optimális szinten maradt a tesztelés során.
Nagyon tetszik számunkra a hosszú távú tesztelés és a megoldások összehasonlításának a megközelítése a bevezetés előtt. Ha szeretné, tesztelhetjük a teljesítményt az Ön terheléseire is. Más hiper-konszolidált megoldásokon is. Az említett ügyfél jelenleg párhuzamosan végez teszteket egy másik megoldáson. Jelenlegi infrastruktúrája csupán egy PC parkból, egy doménból és szoftverből áll minden munkahelyen. Elég nehéz áttérni a VDI-re tesztek nélkül. Kifejezetten nehéz megérteni a VDI farm valódi lehetőségeit anélkül, hogy valós felhasználókat migrálnánk rá. Ezek a tesztek lehetővé teszik a különböző rendszerek valós képességeinek gyors értékelését anélkül, hogy szükség lenne a normál felhasználók bevonására. Ebből ered a kutatás.
A második fontos megközelítés az, hogy az ügyfél azonnal a helyes skálázásra összpontosított. Itt kiegészítő szervert lehet vásárolni, és például egy 100 felhasználós farmot hozzáadni, az ár felhasználónként előre meghatározott. Például amikor még 300 felhasználót kell hozzáadniuk, tudni fogják, hogy két szerverre van szükségük már előre meghatározott konfigurációban, nem pedig a meglévő infrastruktúra modernizálásának lehetőségeit kell átnézniük.
Érdekesek az HPE SimpliVity federációs lehetőségei. Az üzlet földrajzilag megosztott, ezért a távoli irodákba indokolt saját külön VDI berendezést telepíteni. A SimpliVity federációban minden virtuális gép ütemezés szerint replikálódik, lehetőséget biztosítva a földrajzilag távoli klaszterek között való gyors adatátvitelre, minimális terheléssel. Ez egy nagyon jó szintű beépített biztonsági mentés. A VM-ek replikálása között a csatorna annyira minimálisan van igénybe véve, amennyire csak lehetséges, és ez lehetőséget nyújt nagyon érdekes DR architektúrák kialakítására egyetlen irányítási központ és sok decentralizált tárolóhely meglétével.
Mindezek összessége lehetővé teszi, hogy nagyon részletesen értékeljük a pénzügyi oldalt, a VDI költségeit a cég növekedési terveivel összehangolva, és megértsük, milyen gyorsan térül meg a megoldás, és hogyan fog működni. Mert bármelyik VDI olyan megoldás, amely végső soron rengeteg erőforrást takarít meg, de valószínűleg nincs gazdaságilag kedvező lehetőség a csere érdekében 5-7 év használat után.
Összességében, ha kérdéseid maradtak, amelyeket nem szeretnél kommentárokban megosztani, írj nekem az mk@croc.ru e-mail címre.
Forrás: habr.com
