🥇Kuidas töötab HPE SimpliVity 380 VDI jaoks: intensiivsed koormustestid

Tellija soovis VDI-d. Ta jälgis hoolikalt SimpliVity + VDI Citrix Virtual Desktop komplekti. Kõigile operaatoritele, töötajatele kontorites ja nii edasi. Esimeses migratsioonilaines on seal viis tuhat kasutajat, seetõttu nõudsid nad koormustestimist. VDI võib hakata aeglustuma, see võib lihtsalt alla kukkuda – ja see ei juhtu alati kanaliprobleemide tõttu. Ostisime VDI jaoks spetsiaalselt väga võimsa testimise paketi ja koormasime infrastruktuuri, kuni see kukkus diskide ja protsessori tõttu alla.

Nii, meil on vaja plastpudelit, LoginVSI tarkvara keerukate VDI testide jaoks. Meil on see 300 kasutaja litsentsidega. Seejärel võtsime HPE SimpliVity 380 riistvara, mis sobib maksimaalse kasutajatiheduse saavutamiseks ühe serveri kohta, lõikasime välja head üleprioriseeritud virtuaalmasinad, paigaldasime neile kontoritarkvara Win10-s ja alustasime testimist.

Lähme!

Süsteem

Kaks sõlme (serverit) HPE SimpliVity 380 Gen10. Igal neist:

2 x Intel Xeon Platinum 8170 26c 2.1Ghz.
Mälu: 768GB, 12 x 64GB LRDIMMs DDR4 2666MHz.
Peamine diskikontroller: HPE Smart Array P816i-a SR Gen10.
Kõvakettad: 9 x 1.92 TB SATA 6Gb/s SSD (RAID6 7+2 konfiguratsioonis, see tähendab, et see on HPE SimpliVity mõistes Medium mudel).
Võrgukaardid: 4 x 1Gb Eth (kasutajate andmed), 2 x 10Gb Eth (SimpliVity taust ja vMotion).
Igas sõlmes on dedupeerimise/compressiooni jaoks spetsiaalsed sisseehitatud FPGA-kaardid.

Sõlmed on omavahel ühendatud 10Gb Etherneti interconnectiga otse ilma välist switchi, mida kasutatakse SimpliVity taustana ja virtuaalmasinate andmete edastamiseks NFS kaudu. Virtuaalmasinate andmed klastris peegelduvad alati kahe sõlme vahel.

Sõlmed on ühendatud Vmware vSphere klastrisse, mida haldab vCenter.

Testimise läbiviimiseks on rakendatud domeenikontroller ja Citrixi ühenduste vahendaja. Domeenikontroller, vahendaja ja vCenter on eraldi klastrisse paigaldatud.

Testimise infrastruktuuriks on lahendatud 300 virtuaalset töölauad Dedicated – Full Copy konfiguratsioonis, see tähendab, et iga töölaua on täielik koopia originaalsest virtuaalmasina pildist ja salvestab kõik kasutajate tehtud muudatused.

Igal virtuaalsel masinal on 2 vCPU-d ja 4GB RAM:

Virtuaalmasinatele on paigaldatud järgmine tarkvara, mis on vajalik testimise läbiviimiseks:

Windows 10 (64-bit), versioon 1809.
Adobe Reader XI.
Citrix Virtual Delivery Agent 1811.1.
Doro PDF 1.82.
Java 7 Update 13.
Microsoft Office Professional Plus 2016.

Sõlmede vahel toimub sünkroonne replikatsioon. Iga andmablokil klastris on kaks koopiat. See tähendab, et iga sõlm sisaldab täielikku andmekogumit. Kui klaster koosneb kolmest või enamast sõlmest, on andmablokid kahel erineval kohal. Uue virtuaalse masina loomisel luuakse lisakoopia ühel klastris asuvast sõlmest. Kui mõni sõlm rikke tõttu välja langeb, käivituvad kõik varem seal olnud virtuaalsed masinad automaatselt teistele sõlmedele, kus need koopiad on. Kui sõlm on pikaks ajaks rikki läinud, algab järk-järguline üleliigsuse taastamine ja klaster naaseb tagasi N+1 reservidesse.

Andmete tasakaalustamine ja salvestamine toimub SimpliVity enda programmilise salvestussüsteemi tasemel.

Virtuaalsed masinad käivitatakse virtualiseerimisklastris, mis paigutab need programmilisse salvestusse. Tööjaamad said tüüpilise mallide alusel: testimiseks kasutati finants- ja operatiivspetsialistide tööjaamu (need on kaks erinevat mallide tüüpi).

Testimine

Testimise jaoks kasutati testimistarkvara LoginVSI 4.1. LoginVSI kompleks koosneb haldusserverist ja 12 masinast testühenduste jaoks, mis paigutati eraldi füüsilisele hostile.

Testimine toimus kolmes režiimis:

Benchmark-režiim — koormuse variandid, 300 teadmiste töötajat ja 300 salvestustöötajat.

Standardrežiim — koormuse variant, 300 energia töötajat.

Energia töötajate töövõime ja koormuse mitmekesistamise võimaldamiseks on LoginVSI kompleksile lisatud Power Library täiendavate failide teek. Tulemuste korduvuse tagamiseks jäeti kõik testimise seadistused vaikeseadeteks.

Teadmiste ja energia töötajate testid simuleerivad tegelikku koormust kasutajatel, kes töötavad virtuaalsetel tööjaamadel.

Salvestustöötajate test on loodud spetsiaalselt andmesalvestussüsteemide testimiseks, see on kaugel reaalsetest koormustest ja koosneb peamiselt kasutaja tegevustest, mis on seotud suure hulga erineva suurusega failidega.

Testimise käigus logivad kasutajad tööjaamadesse 48 minuti jooksul, umbes üks kasutaja iga 10 sekundi järel.

tulemused näitasid ainult nelja ebaolulise koodibloki kattuvust, mis olid tingitud POSIX ja ANSI C nõuetest.

LoginVSI testimise peamine tulemus on VSImax mõõdik, mis koostatakse erinevate ülesannete täitmise ajast, mida kasutaja käivitab. Näiteks: faili avamise aeg Notepad'is, faili tihendamise aeg 7-Zip'is jne.

Üksikasjalik kirjeldus meetrikate jälgimisest on saadaval ametlikus dokumentatsioonis lingil.

Teisisõnu, LoginVSI kordab tüüpilist koormusmustrit, simuleerides kasutaja tegevusi kontoritarkvaras, PDF-failide lugemisel ja mujal, mõõtes erinevaid viivitusi. On kriitiline viivituste tase, mille juures "kõik hangub, töötamine on võimatu"), kuni selle saavutamiseni peetakse, et maksimumkasutajate arv ei ole saavutatud. Kui vastusaeg on 1 000 ms kiirem kui see seisund "kõik hangub", peetakse süsteemi normaalselt töötavaks ja on võimalik lisada veel kasutajaid.

Siin on põhimõttelised meetrikad:

Metrika

Teostatavad toimingud

Üksikasjalik kirjeldus

Koormatud komponendid

NSLD

Tekstifaili avamise aeg
faili suurusega 1 500 KB

Avatakse Notepad ja
avatakse juhuslikult dokument suurusega 1 500 KB, mis on kopeeritud ressursside kogumist
ressursside

CPU ja I/O

NFO

Dialooge avamise aeg Notepadis
Faili avamine VSI-Notepad [Ctrl+O]

CPU, RAM ja I/O

ZHC*

Zip-faili loomise aeg tugeva kokkusurutusega

5 MB suuruse .pst-formaadis kohaliku juhusliku faili kokkusurumine, mis on kopeeritud

ressursside kogumist
ZLC*
Zip-faili loomise aeg nõrga kokkusurutusega

CPU ja I/O

I/O

Suurte juhuslike andmete massiivi arvutamine

ressursside kogumist
ZLC*
Zip-faili loomise aeg nõrga kokkusurutusega

Suurte juhuslike andmete massiivi loomine, mida kasutatakse I/O-timere sisendiks

CPU

Testimise käigus arvutatakse esialgne VSIbase metrika, mis näitab ülesannete täitmise kiirus, ilma süsteemi koormuseta. Selle alusel määratakse VSImax künnis, mis on võrdne VSIbase + 1 000ms.
Süsteemi jõudluse järeldused põhinevad kahel meetrikal: VSIbase, mis määrab süsteemi töökõrvalduse kiirus ja VSImax künnis, mis määrab maksimaalse kasutajate arvu, mida süsteem talub ilma olulise halvenemiseta.

300 teadmiste töötaja benchmark
Teadmiste töötajad on kasutajad, kes regulaarselt koormavad mälu, protsessorit ja I/O erinevate väikeste harjude kaudu. Tarkvara simuleerib koormust nõudlikelt kontori kasutajatelt, nagu nad pidevalt midagi vajutavad (PDF, Java, kontoritarkvara, piltide vaatamine, 7-Zip). Kasutajate arvu suurenedes nullist kuni 300 suureneb igaühe viivitus sujuvalt.

CPU

VSImax statistika:

VSIbase = 986ms, VSI künnist ei saavutatud.

Salvestusüsteemi koormuse statistika SimpliVity seirest:

300 Knowledge workers benchmark

Knowledge workers — это юзеры, которые регулярно нагружают память, процессор и IO разными мелкими пиками. Софт эмулирует нагрузку с требовательных офисных пользователей, как будто они постоянно что-то тыкают (PDF, Java, офисный пакет, просмотр фото, 7-Zip). По мере добавления пользователей с нуля до 300 задержка у каждого плавно растёт.

Данные статистики VSImax:

Статистика нагрузки на систему хранения из мониторинга SimpliVity:

Selle koormuse tüübi puhul suudab süsteem taluda koormuse suurenemist praktiliselt ilma jõudluse halvenemiseta. Kasutajate ülesannete täitmise aeg suureneb sujuvalt, süsteemi reageerimise aeg ei muutu testimise käigus ning jääb kirjutamisel kuni 3 ms ja lugemisel kuni 1 ms.

Kokkuvõte: 300 knowledge kasutajat töötavad hetkelises klastris probleemideta ja ei sega üksteist, saavutades pCPU/vCPU suhe 1:6. Üldine latentsus koormuse suurenemisega kasvab ühtlaselt, kuid piirangut ei ole saavutatud.

300 Storage workers benchmark

Need on kasutajad, kes kirjutavad ja loevad pidevalt suhtega 30:70. See test viidi läbi pigem eksperimendi eesmärgil. VSImax statistika:

VSIbase = 1673, VSI Threshold saavutati 240 kasutajal.

Статистика нагрузки на систему хранения из мониторинга SimpliVity:

Selle tüüpi koormus on põhimõtteliselt süsteemi ladustamise stressitest. Selle täitmisel kirjutab iga kasutaja kettale hulga juhuslikke faile erinevates suurustes. Sel juhul on näha, et kui koormus ületab teatud piiri, suureneb osa kasutajate jaoks failide kirjutamise ülesannete täitmise aeg. Samal ajal ei muutu koormus ladustamissüsteemile, hostide protsessorile ja mälule oluliselt, mistõttu ei saa praegu täpselt kindlaks teha, millega viivitused seotud on.

Selle testi tulemusi süsteemi jõudluse kohta saab teha ainult võrreldes teiste süsteemide testitulemustega, kuna sellised koormused on sünteetilised, mitterealistlikud. Siiski , ühiselt test läks kenasti. Kuni 210 sessioonini läks kõik hästi, seejärel algasid arusaamatud reageeringud, mida samas ei jälgitud kusagil mujal, välja arvatud Login VSI.

300 Power workers

Need on kasutajad, kes hindavad protsessorit, mälu ja kõrgeid IO-sid. Need "edukad kasutajad" käivitavad regulaarselt keerulisi ülesandeid pikaajaliste tipudega, näiteks uue tarkvara installimist ja suurte arhiivide dekompressimist. VSImax statistika:

VSIbase = 970, VSI Threshold ei olnud saavutatud.

Статистика нагрузки на систему хранения из мониторинга SimpliVity:

Testimise käigus saavutati koormuse piiri tase ühe süsteemi sõlme protsessorites, kuid see ei avaldanud süsteemi tööle olulist mõju:

Selline süsteem talub koormuse suurenemist ilma mingisuguste märgatavate jõudluse langusteta. Kasutajate ülesannete täitmise aeg kasvab sujuvalt, süsteemi vastuse aeg ei muutu katsete käigus ning jääb kuni 3 ms kirjutamise ja kuni 1 ms lugemise jaoks.

Tavalisest testimisest ei piisunud tellijale, ning me läksime kaugemale: suurendasime VM-i omadusi (vCPU arv, et hinnata ümberasumist ja ruumi suurust) ning lisasime täiendava koormuse.

Täiendavate testide läbiviimise ajal kasutati järgmisi stendi konfiguratsioone:
Konfigureeritud on 300 virtuaalset töölauda, milles on 4vCPU, 4GB RAM ja 80GB HDD.

Ühe katse masina konfiguratsioon:

Masinad on seadistatud Dedicated - Full Copy variandis:

300 teadustöötajaid, benchmark koos 12-kordse ümberasumisega

Статистика нагрузки на систему хранения из мониторинга SimpliVity:

Saadud tulemused on sarnased eelmise VM-i konfiguratsiooni testimisega.

300 Power workers koos 12-kordse ümberasumisega

Статистика нагрузки на систему хранения из мониторинга SimpliVity:

Sellel testimisel saavutati samuti protsessorite koormuse lävi, kuid see ei avaldanud olulist mõju jõudlusele:

Saadud tulemused on sarnased eelmise konfiguratsiooni testimisega.

Mis juhtub, kui koormust käivitada 10 tunni jooksul?

Nüüd vaatame, kas ilmneb 'kogumise efekt' ja teeme testid järjestikku 10 tunni jooksul.

Pikad testid ja jaotise kirjeldus peaksid olema suunatud sellele, mida me soovisime kontrollida, kas jagu kohta ilmnevad mingid probleemid pikaajalise koormuse all.

300 teadustöötajaid, benchmark + 10 tundi

Lisaks viidi läbi 300 teadustöötaja koormuse vähendamise katse, millele järgneb 10 tunni jooksul kasutajate töö.

VSImax Detail statistika:

Graafik näitab, et kogu katse vältel ei esinenud jõudluse langust.

Статистика нагрузки на систему хранения из мониторинга SimpliVity:

Salvestussüsteemi jõudlus jääb kogu katse vältel ühtlaseks.

Lisakatse, kus lisati sünteetiline koormus.

Kliendi palveks lisada kettale intensiivset koormust. Selleks lisati iga kasutaja virtuaalmasina salvestussüsteemi ülesanne käivitada sünteetiline kettakoormus, kui kasutaja logib süsteemi sisse. Koormust tagas utiliit fio, mis võimaldab piirata kettakoormust IOPS-i arvu järgi. Igas masinas käivitati ülesanne, mis genereeris 22 IOPS 70 %/30 % juhusliku lugemise/kirjutamisega.

300 teadmiste töötaja test + 22 IOPS iga kasutaja kohta

Esialgse testimise käigus selgus, et fio tekitab virtuaalmasinate seadmetele märkimisväärset täiendavat koormust. See tõi kaasa hostide kiire ülekoormuse CPU-lt ning avaldas tugevat mõju kogu süsteemi toimimisele.

Hostide CPU koormus:

Salvestussüsteemi viivitused suurenesid vastavalt:

Arvutusvõimsuse puudujääk muutus kriitiliseks umbes 240 kasutaja juures:

Saadud tulemuste tõttu otsustati teostada vähem CPU-d koormavaid teste.

230 kontoritöötaja testi + 22 IOPS iga kasutaja kohta

CPU koormuse vähendamiseks valiti kontoritöötajate koormuse tüüp, igale sessioonile lisati samuti 22 IOPS sünteetilist koormust.

Test piiratud 230 sessiooniga, et mitte ületada maksimaalset CPU koormust.

Test käivitus järgneva kasutajate tööga 10 tunni jooksul, et kontrollida süsteemi stabiilsust pikaajalise töötamise ajal, mis oli lähedane maksimaalsele koormusele.

VSImax Detail statistika:

Graafik näitab, et kogu katse vältel ei esinenud jõudluse langust.

CPU koormuse statistika:

Selle testi käigus oli hostide CPU koormus peaaegu maksimaalne.

Статистика нагрузки на систему хранения из мониторинга SimpliVity:

Salvestussüsteemi jõudlus jääb kogu katse vältel ühtlaseks.

Salvestussüsteemi koormus testi ajal oli umbes 6 500 IOPS suhe 60/40 (3 900 IOPS – lugemisel, 2 600 IOPS – kirjutamisel), mis teeb vähemalt 28 IOPS iga tööjaama kohta.

Keskmine reageerimisaeg oli 3 ms kirjutamisel ja kuni 1 ms lugemisel.

Kokkuvõte

HPE SimpliVity infrastruktuuri reaalsete koormuste modelleerimisel saadi tulemused, mis kinnitavad süsteemi võimet toetada vähemalt 300 täiskoopia virtuaalset töölauda SimpliVity sõlmede paaris. Samuti püsis salvestussüsteemi reageerimisaeg kogu testimise vältel optimaalsel tasemel.

Meie jaoks on väga oluline lähenemine pikaajaliste testide ja lahenduste võrdlemise osas enne rakendamist. Kui soovite, saame testida jõudlust ka teie koormuste jaoks, sealhulgas muude hüperkonvergeeritud lahenduste puhul. Mainitud klient lõpetab praegu teiste lahenduste testimist paralleelselt. Tema praegune infrastruktuur on lihtsalt PC-de park, domeen ja tarkvara igas töökohtades. Üleminek VDI-le ilma testideta on kindlasti üsna keeruline. Üksikute kasutajate migratsioonita on keeruline mõista VDI farmi reaalset potentsiaali. Need testid võimaldavad kiirelt hinnata erinevate süsteemide reaalseid võimalusi ilma tavaliste kasutajate kaasamiseta. Sealt tuli ka selline uuring.

Teine oluline lähenemine on, et klient kavandas õigesti skaleerimise. Siin on võimalik osta server ja lisada näiteks 100 kasutajaga farm, kõik on kasutaja hinna osas etteennustatav. Näiteks, kui nad peavad lisama veel 300 kasutajat, siis nad teavad, et on vaja kahte serverit juba kindlas konfiguratsioonis, mitte vaadata uuesti oma infrastruktuuri uuendamise võimalusi tervikuna.

Huvitavad on HPE SimpliVity föderatsiooni võimalused. Äri on geograafiliselt jaotatud, seetõttu on mõistlik kaugkontorisse paigaldada oma eraldi VDI riistvara. SimpliVity föderatsioonis replikatsioon toimub ajakava alusel, võimaldades geograafiliselt kaugete klastrite vahel väga kiiresti ja koormuseta kanalile — see on sisseehitatud väga hea tasemega varukoopia. VM-i replikatsiooni korral on kanali kasutamine minimaalne, nii palju kui võimalik, ning see loob võimalusi väga huvitavate DR-arkitektuuride loomiseks, kui on olemas ühtne juhtimiskeskus ja hulk detsentraliseeritud salvestusplatvorme.

Föderatsioon

Kõik see kokku annab võimaluse hinnata ka finantsaspekti väga detailselt, koormata VDI kulud ettevõtte kasvuplaanidega ja mõista, kui kiiresti lahendus tasub end ära ja kuidas see töötab. Kuna iga VDI on lahendus, mis lõpuks säästab palju ressursse, kuid tõenäoliselt ei ole majanduslikult mõistlik seda muuta 5–7 aasta jooksul.

Kui teil on küsimusi, mis ei kuulu kommentaaridesse, kirjutage mulle aadressil mk@croc.ru.

Allikas: habr.com