Az ügyfél VDI-t akart. Nagyon megnéztem a SimpliVity + VDI Citrix Virtual Desktop kombinációt. Minden üzemeltetőnek, városi hivatal alkalmazottjának stb. Csak az első migrációs hullámban ötezer felhasználó van, ezért ragaszkodtak a terhelési teszteléshez. A VDI elkezdhet lassulni, nyugodtan feküdhet le - és ez nem mindig a csatorna problémái miatt következik be. Vásároltunk egy nagyon erős tesztcsomagot kifejezetten VDI-hez, és addig terheltük az infrastruktúrát, amíg túl nehéz lett a lemezeken és a processzoron.
Tehát szükségünk lesz egy műanyag palackra és a LoginVSI szoftverre a kifinomult VDI-tesztekhez. 300 felhasználóra szóló licencünk van. Ezután a HPE SimpliVity 380-as hardvert a szerverenkénti maximális felhasználósűrűség feladatának megfelelő csomagban vettük, feldaraboltuk a jó túlfizetéssel rendelkező virtuális gépeket, telepítettük az irodai szoftvereket Win10-re és elkezdtük a tesztelést.
Gyerünk!
Rendszer
Két HPE SimpliVity 380 Gen10 csomópont (szerver). Mindegyiken:
- 2 x Intel Xeon Platinum 8170 26c 2.1 GHz.
- RAM: 768 GB, 12 x 64 GB LRDIMM DDR4 2666 MHz.
- Elsődleges lemezvezérlő: HPE Smart Array P816i-a SR Gen10.
- Merevlemezek: 9 x 1.92 TB SATA 6Gb/s SSD (RAID6 7+2 konfigurációban, azaz ez HPE SimpliVity kifejezéssel Medium modell).
- Hálózati kártyák: 4 x 1 Gb Eth (felhasználói adatok), 2 x 10 Gb Eth (SimpliVity és vMotion háttér).
- Speciális beépített FPGA kártyák minden csomópontban a deduplikáció/tömörítés érdekében.
A csomópontok egy 10 Gb-os Ethernet-összeköttetésen keresztül csatlakoznak egymáshoz közvetlenül, külső switch nélkül, amely SimpliVity háttérrendszerként és virtuális gép adatok NFS-en keresztüli átvitelére szolgál. A fürtben lévő virtuális gép adatai mindig tükröződnek két csomópont között.
A csomópontokat a vCenter által kezelt Vmware vSphere fürtbe egyesítik.
A teszteléshez egy tartományvezérlőt és egy Citrix kapcsolatközvetítőt telepítettek. A tartományvezérlő, a közvetítő és a vCenter külön fürtben található.
Tesztinfrastruktúraként 300 virtuális asztal került telepítésre a Dedicated – Full Copy konfigurációban, azaz minden asztal a virtuális gép eredeti képének teljes másolata, és elmenti a felhasználók által végrehajtott összes módosítást.
Minden virtuális gép 2v CPU-val és 4 GB RAM-mal rendelkezik:
A teszteléshez szükséges szoftverek a következő telepítésre kerültek a virtuális gépekre:
- Windows 10 (64 bites), 1809-es verzió.
- Adobe Reader XI.
- Citrix Virtual Delivery Agent 1811.1.
- Doro PDF 1.82.
- Java 7 frissítés 13.
- Microsoft Office Professional Plus 2016.
Csomópontok között - szinkron replikáció. A fürt minden adatblokkjának két másolata van. Vagyis most minden csomóponton teljes adatkészlet található. Három vagy több csomópontból álló fürt esetén a blokkok másolatai két különböző helyen találhatók. Új virtuális gép létrehozásakor egy további másolat jön létre az egyik fürtcsomóponton. Ha egy csomópont meghibásodik, a korábban azon futó összes virtuális gép automatikusan újraindul a többi csomóponton, ahol replikákkal rendelkeznek. Ha egy csomópont hosszú ideig meghibásodik, akkor megkezdődik a redundancia fokozatos helyreállítása, és a fürt visszatér N+1 redundanciához.
Az adatkiegyenlítés és tárolás a SimpliVity szoftvertárolási szintjén történik.
A virtuális gépek virtualizációs fürtöt futtatnak, amely szintén szoftvertárhelyre helyezi őket. Magukat az íróasztalokat egy szabványos sablon szerint vettük: a pénzügyőrök és az operatív tisztek asztalai jöttek a tesztre (ez két különböző sablon).
tesztelés
A teszteléshez a LoginVSI 4.1 szoftvertesztet használtuk. A LoginVSI komplexum, amely egy vezérlőkiszolgálóból és 12 tesztkapcsolatot biztosító gépből áll, egy külön fizikai gazdagépen került telepítésre.
A tesztelés három módban történt:
Összehasonlító mód – 300 tudással rendelkező dolgozó és 300 raktári dolgozó betöltése.
Normál üzemmód - terheléses eset 300 Power worker.
Annak érdekében, hogy a Power dolgozók dolgozhassanak és növeljék a terhelések sokféleségét, a LoginVSI komplexhez egy további Power Library fájlokat tartalmazó könyvtárat adtunk. Az eredmények megismételhetőségének biztosítása érdekében az összes tesztpadi beállítást alapértelmezettként hagytuk meg.
A Knowledge and Power Worker tesztek a virtuális munkaállomásokon dolgozó felhasználók valós munkaterhelését szimulálják.
A Tárolódolgozók tesztet kifejezetten az adattároló rendszerek tesztelésére hozták létre, távol áll a valós terheléstől, és többnyire nagyszámú, különböző méretű fájllal dolgozik a felhasználó.
A tesztelés során a felhasználók 48 percre bejelentkeznek a munkaállomásokra, körülbelül egy felhasználó 10 másodpercenként.
Álláspontja
A LoginVSI tesztelés fő eredménye a VSImax metrika, amelyet a felhasználó által elindított különféle feladatok végrehajtási idejéből állítanak össze. Például: ideje megnyitni egy fájlt a Jegyzettömbben, ideje tömöríteni egy fájlt 7-Zip formátumban stb.
A mérőszámok számításának részletes leírása a hivatalos dokumentációban található .
Más szavakkal, a LoginVSI megismétel egy tipikus betöltési mintát, szimulálja a felhasználói műveleteket egy irodai programcsomagban, olvassa el a PDF-eket és így tovább, és különféle késéseket mér. A késések kritikus szintje „minden lelassul, nem lehet dolgozni”), amely előtt úgy tekintik, hogy nem érték el a maximális felhasználók számát. Ha a válaszidő 1 ms-mal gyorsabb, mint ez a „minden lassú” állapot, akkor a rendszer normálisan működik, és további felhasználók vehetők fel.
Íme a főbb mutatók:
Mérések
Megtett intézkedések
Részletes описание
Betöltött alkatrészek
N.S.L.D.
Szöveg nyitási ideje
1 KB tömegű fájl
Megnyílik a Jegyzettömb és
megnyit egy véletlenszerű 1 KB-os dokumentumot, amely a készletből másolt
erőforrások
CPU és I/O
NFO
Párbeszéd nyitva tartása
ablakok a jegyzettömbben
VSI-Notepad fájl megnyitása [Ctrl+O]
CPU, RAM és I/O
ZHC*
Ideje létrehozni egy erősen tömörített ZIP-fájlt
Helyi tömörítés
véletlenszerű 5 MB .pst fájl másolása innen
erőforráskészlet
CPU és I/O
ZLC*
Ideje gyengén tömörített ZIP-fájlt létrehozni
Helyi tömörítés
véletlenszerű 5 MB .pst fájl másolása innen
erőforráskészlet
I / O
CPU
Nagy számítás
véletlenszerű adattömb
Nagy tömb létrehozása
véletlenszerű adatok, amelyeket a bemeneti/kimeneti időzítő (I/O időzítő) használ
CPU
A tesztelés során először az alapvető VSIbase mérőszámot számítják ki, amely azt mutatja meg, hogy milyen sebességgel hajtanak végre feladatokat a rendszer terhelése nélkül. Ez alapján kerül meghatározásra a VSImax Threshold, ami egyenlő a VSIbase + 1 ms értékkel.
A rendszer teljesítményére vonatkozó következtetéseket két mérőszám alapján vonjuk le: a VSIbase, amely meghatározza a rendszer sebességét, és a VSImax küszöb, amely meghatározza, hogy a rendszer hány felhasználót tud kezelni jelentős romlás nélkül.
300 Knowledge Workers benchmark
A tudásmunkások olyan felhasználók, akik rendszeresen betöltik a memóriát, a processzort és az IO-t különféle kis csúcsokkal. A szoftver az igényes irodai felhasználók leterheltségét emulálja, mintha folyamatosan piszkálnának valamit (PDF, Java, irodai programcsomag, fotómegtekintés, 7-Zip). Ahogy nulláról 300-ra ad hozzá felhasználókat, mindegyiknél fokozatosan növekszik a késleltetés.
VSImax statisztikai adatok:
VSIbase = 986 ms, a VSI küszöbértéket nem érte el.
A tárolórendszer terhelési statisztikái a SimpliVity figyelésből:
Az ilyen típusú terhelés mellett a rendszer a teljesítmény romlása nélkül képes ellenállni a megnövekedett terhelésnek. A felhasználói feladatok elvégzéséhez szükséges idő zökkenőmentesen növekszik, a rendszer válaszideje nem változik a tesztelés során, és legfeljebb 3 ms írásnál és 1 ms olvasásnál.
Következtetés: 300 tudásfelhasználó problémamentesen dolgozik az aktuális klaszteren, és nem zavarják egymást, elérve a pCPU/vCPU 1-től 6-ig terjedő túljelentkezést. A teljes késések a terhelés növekedésével egyenletesen nőnek, de az előírt határértéket nem érték el.
300 raktári dolgozó benchmark
Ezek olyan felhasználók, akik folyamatosan írnak és olvasnak 30-70 arányban. Ezt a tesztet inkább a kísérletezés kedvéért végezték el. VSImax statisztikai adatok:
VSIbase = 1673, a VSI-küszöböt 240 felhasználónál érte el.
A tárolórendszer terhelési statisztikái a SimpliVity figyelésből:
Ez a fajta terhelés lényegében a tárolórendszer stressztesztje. Amikor végrehajtja, minden felhasználó sok véletlenszerű, különböző méretű fájlt ír a lemezre. Ebben az esetben látható, hogy amikor egyes felhasználók túllépnek egy bizonyos terhelési küszöböt, megnő a fájlok írási feladatainak végrehajtásához szükséges idő. Ugyanakkor a gazdagépek tárolórendszerének, processzorának és memóriájának terhelése nem változik jelentősen, így jelenleg nem lehet pontosan meghatározni, hogy mi okozza a késéseket.
A rendszer teljesítményére vonatkozó következtetéseket ezzel a teszttel csak más rendszereken végzett teszteredményekhez képest lehet levonni, mivel az ilyen terhelések szintetikusak és irreálisak. A teszt azonban összességében jól sikerült. 210 munkamenetig minden jól ment, aztán furcsa válaszok kezdődtek, amelyeket a Login VSI-n kívül sehol nem követtek nyomon.
300 erőműves
Ezek olyan felhasználók, akik szeretik a CPU-t, a memóriát és a magas IO-t. Ezek az „erős felhasználók” rendszeresen hajtanak végre összetett feladatokat hosszú sorozatokkal, például új szoftverek telepítését és nagy archívumok kicsomagolását. VSImax statisztikai adatok:
VSIbase = 970, a VSI-küszöböt nem érte el.
A tárolórendszer terhelési statisztikái a SimpliVity figyelésből:
A tesztelés során az egyik rendszercsomóponton elérték a processzorterhelési küszöbértéket, de ennek nem volt jelentős hatása annak működésére:
Ebben az esetben a rendszer a teljesítmény jelentős romlása nélkül képes ellenállni a megnövekedett terhelésnek. A felhasználói feladatok elvégzéséhez szükséges idő zökkenőmentesen növekszik, a rendszer válaszideje nem változik a tesztelés során, és legfeljebb 3 ms írásnál és 1 ms olvasásnál.
A rendszeres tesztek nem voltak elegendőek az ügyfél számára, és tovább mentünk: növeltük a virtuális gép jellemzőit (a vCPU-k számát a túljelentkezés és a lemezméret növekedésének értékeléséhez), és további terhelést adtunk.
A további vizsgálatok során a következő állványkonfigurációt használtuk:
300 virtuális asztali számítógépet telepítettek 4v CPU-val, 4 GB RAM-mal és 80 GB HDD-vel.
Az egyik tesztgép konfigurációja:
A gépek a Dedikált – Teljes másolás opcióban vannak telepítve:
300 Knowledge Workers benchmark túljelentkezéssel 12
VSImax statisztikai adatok:
VSIbase = 921 ms, a VSI küszöbértéket nem érte el.
A tárolórendszer terhelési statisztikái a SimpliVity figyelésből:
A kapott eredmények hasonlóak az előző virtuális gép-konfiguráció teszteléséhez.
300 erőműves 12 túljelentkezéssel
VSImax statisztikai adatok:
VSIbase = 933, a VSI-küszöböt nem érte el.
A tárolórendszer terhelési statisztikái a SimpliVity figyelésből:
A tesztelés során a processzorterhelési küszöböt is elértük, de ez nem volt jelentős hatással a teljesítményre:
A kapott eredmények hasonlóak az előző konfiguráció teszteléséhez.
Mi történik, ha 10 órán keresztül futja a terhelést?
Most nézzük meg, lesz-e „felhalmozási hatás”, és végezzünk teszteket 10 órán keresztül egymás után.
A hosszú távú tesztek és a szakasz leírása arra irányuljon, hogy ellenőrizni akartuk, hogy a rácsos rácsos hosszan tartó terhelés esetén nem keletkezik-e probléma.
300 tudásmunkás benchmark + 10 óra
Ezenkívül egy 300 tudásmunkás terhelési esetét tesztelték, majd 10 órás felhasználói munkát végeztek.
VSImax statisztikai adatok:
VSIbase = 919 ms, a VSI küszöbértéket nem érte el.
VSImax Részletes statisztikai adatok:
A grafikon azt mutatja, hogy a teljes teszt során nem figyeltek meg teljesítményromlást.
A tárolórendszer terhelési statisztikái a SimpliVity figyelésből:
A tárolórendszer teljesítménye változatlan marad a teszt alatt.
További tesztelés szintetikus terhelés hozzáadásával
Az ügyfél azt kérte, hogy adjanak hozzá egy vad terhelést a lemezhez. Ennek érdekében a felhasználó minden egyes virtuális gépében hozzáadtak egy feladatot a tárolórendszerhez, amely szintetikus terhelést futtat a lemezen, amikor a felhasználó bejelentkezik a rendszerbe. A terhelést a fio segédprogram biztosította, amely lehetővé teszi a lemez terhelésének korlátozását az IOPS számával. Mindegyik gépen elindítottak egy feladatot egy további terhelés indítására 22 IOPS 70%/30% Random Read/Write értékben.
300 Knowledge Worker benchmark + 22 IOPS felhasználónként
A kezdeti tesztelés során azt találták, hogy a fio jelentős CPU-ráfordítást ró a virtuális gépekre. Ez a gazdagépek gyors CPU-túlterheléséhez vezetett, és nagymértékben befolyásolta a rendszer egészének működését.
Gazda CPU terhelése:
Ugyanakkor természetesen megnőtt a tárolási rendszer késése is:
A számítási teljesítmény hiánya körülbelül 240 felhasználónál vált kritikussá:
A kapott eredmények miatt kevésbé CPU-igényes tesztelés mellett döntöttek.
230 irodai dolgozó benchmark + 22 IOPS felhasználónként
A CPU terhelésének csökkentése érdekében az Office dolgozói betöltési típust választották, és minden munkamenethez 22 IOPS szintetikus terhelést is hozzáadtak.
A teszt 230 munkamenetre korlátozódott, hogy ne lépje túl a maximális CPU-terhelést.
A tesztet 10 órán át tartó felhasználókkal futtatták, hogy ellenőrizzék a rendszer stabilitását hosszú távú, a maximális terheléshez közeli működés során.
VSImax statisztikai adatok:
VSIbase = 918 ms, a VSI küszöbértéket nem érte el.
VSImax Részletes statisztikai adatok:
A grafikon azt mutatja, hogy a teljes teszt során nem figyeltek meg teljesítményromlást.
CPU terhelési statisztika:
A teszt végrehajtásakor a gazdagép CPU-jának terhelése majdnem maximális volt.
A tárolórendszer terhelési statisztikái a SimpliVity figyelésből:
A tárolórendszer teljesítménye változatlan marad a teszt alatt.
A tárolórendszer terhelése a teszt során körülbelül 6 IOPS volt 500/60 arányban (40 IOPS olvasás, 3 IOPS írás), ami munkaállomásonként hozzávetőleg 900 IOPS.
A válaszidő átlagosan 3 ms volt írásnál és legfeljebb 1 ms olvasásnál.
Teljes
A HPE SimpliVity infrastruktúra valós terheléseinek szimulálásakor olyan eredmények születtek, amelyek megerősítették a rendszer azon képességét, hogy támogassa a legalább 300 Full Clone gép virtuális asztalait egy pár SimpliVity csomóponton. Ugyanakkor a tárolórendszer válaszideje a teljes tesztelés során optimális szinten maradt.
Nagyon lenyűgözött bennünket a hosszú tesztek és a megoldások megvalósítás előtti összehasonlítása. Igény szerint tesztelhetjük a teljesítményt az Ön munkaterheléséhez is. Más hiperkonvergens megoldásokat is beleértve. Az említett ügyfél most párhuzamosan egy másik megoldás tesztelését fejezi be. Jelenlegi infrastruktúrája egyszerűen egy számítógép-flotta, egy tartomány és egy szoftver minden munkahelyen. A VDI-re való átállás tesztek nélkül természetesen meglehetősen nehéz. Pontosabban, nehéz megérteni egy VDI-farm valós képességeit anélkül, hogy valódi felhasználókat migrálnánk rá. Ezek a tesztek pedig lehetővé teszik egy adott rendszer valós képességeinek gyors értékelését anélkül, hogy közönséges felhasználókat kellene bevonni. Innen származik ez a tanulmány.
A második fontos megközelítés az, hogy az ügyfél azonnal elkötelezze magát a megfelelő méretezés mellett. Itt lehet vásárolni egy további szervert és hozzáadni egy farmot, például 100 felhasználó számára, felhasználói áron minden kiszámítható. Például, ha további 300 felhasználót kell hozzáadniuk, akkor tudni fogják, hogy két szerverre van szükségük egy már meghatározott konfigurációban, ahelyett, hogy meggondolnák a teljes infrastruktúra frissítését.
Érdekesek a HPE SimpliVity szövetség lehetőségei. Az üzlet földrajzilag elkülönült, ezért célszerű egy távoli irodában saját különálló VDI hardvert telepíteni. A SimpliVity összevonásban minden virtuális gép egy ütemezés szerint replikálódik, és nagyon gyorsan és a csatorna terhelése nélkül replikálható a földrajzilag távoli fürtök között – ez egy nagyon jó szintű beépített biztonsági másolat. A virtuális gépek helyek közötti replikálásakor a csatorna a lehető legminimálisabb felhasználásra kerül, és ez nagyon érdekes DR-architektúrákat tesz lehetővé egyetlen vezérlőközpont és egy csomó decentralizált tárolóhely jelenlétében.
Mindezek együttesen lehetővé teszik a pénzügyi oldal részletes értékelését, a VDI költségeinek rárakását a vállalat növekedési terveire, illetve annak megértését, hogy a megoldás milyen gyorsan térül meg és hogyan fog működni. Mert minden VDI olyan megoldás, amivel végső soron rengeteg erőforrást takarítanak meg, ugyanakkor nagy valószínűséggel anélkül, hogy a használattól számított 5-7 éven belüli költséghatékony cserére lenne lehetőség.
Általánosságban elmondható, hogy ha bármilyen kérdése van, amelyhez nem tartozik megjegyzés, írjon nekem e-mailben [e-mail védett].
Forrás: will.com