Klienti deshi VDI. Ai ishte shumë i interesuar për kombinimin SimpliVity + VDI Citrix Virtual Desktop. Për të gjithë operatorët, punonjësit e zyrave në qytete dhe kështu me radhë. Aty ka pesë mijë përdorues vetëm në valën e parë të migrimit, prandaj ata insistuan në testimin e ngarkesës. VDI mund të fillojë të shkojë ngadalë, mund të mbetet në vend — dhe nuk ndodhi gjithmonë për shkak të problemeve me kanalin. Ne blejmë një paketë testimi shumë të fuqishme posaçërisht për VDI dhe ngarkuam infrastrukturën derisa ajo ra për shkak të disqeve dhe procesorit.
Pra, na duhen një shishe plastike, software-i LoginVSI për teste të avancuara VDI. Ne e kemi atë me licenca për 300 përdorues. Më pas morëm harduerin HPE SimpliVity 380 në një konfigurim të përshtatshëm për detyrën e përfitimit maksimal të përdoruesve në një server, ndamë makinat virtuale me një riparim të mirë, vendosëm mbi to softin e zyrës në Win10 dhe filluam testimin.
Fillojmë!
Sistemi
Dy nyje (serverë) HPE SimpliVity 380 Gen10. Në secilën:
- 2 x Intel Xeon Platinum 8170 26c 2.1Ghz.
- Memoria RAM: 768GB, 12 x 64GB LRDIMMs DDR4 2666MHz.
- Kontrolluesi i diskëve kryesor: HPE Smart Array P816i-a SR Gen10.
- Disqet e forta: 9 x 1.92 TB SATA 6Gb/s SSD (në konfigurim RAID6 7+2, dmth. kjo është modeli Medium në terma të HPE SimpliVity).
- Kartat e rrjetit: 4 x 1Gb Eth (të dhënat e përdoruesve), 2 x 10Gb Eth (backend SimpliVity dhe vMotion).
- Kartat FPGA të integruara në çdo nyje për deduplikimin/përkompresimin.
Nyjet janë lidhur mes tyre me një interkonekt 10Gb Ethernet direkt pa ndonjë switch të jashtëm, i cili përdoret si backend SimpliVity dhe për transferimin e të dhënave të makinave virtuale përmes NFS. Të dhënat e makinave virtuale në grupin janë gjithmonë të pasqyruara mes dy nyjave.
Nyjet janë të bashkuara në një klaster Vmware vSphere nën menaxhimin e vCenter.
Për zhvillimin e testeve është vendosur një kontrollues domene dhe një broker lidhjesh Citrix. Kontrolluesi i domeneve, brokeri dhe vCenter janë vendosur në një klaster të veçantë.
Si infrastrukturë testimi janë vendosur 300 tavolina virtuale në konfigurimin Dedicated – Full Copy, dmth. çdo tavolinë virtuale është një kopje e plotë e imazhit origjinal të makinës virtuale dhe ruan të gjitha ndryshimet e bërë nga përdoruesit.
Çdo makinë virtuale ka 2vCPU dhe 4GB RAM:
Në makinat virtuale ishte instaluar softi i mëposhtëm, i nevojshëm për realizimin e testimit:
- Windows 10 (64-bit), versioni 1809.
- Adobe Reader XI.
- Citrix Virtual Delivery Agent 1811.1.
- Doro PDF 1.82.
- Java 7 Update 13.
- Microsoft Office Professional Plus 2016.
Mes nyjave — replikimi sinkron. Çdo bllok të dhënash në grup ka dy kopje. Pra tani ka një set të plotë të dhënash në secilën nga nyjat. Me klaster në tre e më shumë nyje — kopjet e bllokave janë në dy vende të ndryshme. Kur krijohet një VM, krijohet një kopje shtesë në një nga nyjat e klasterit. Nëse një nyje dështon për një kohë të gjatë, të gjitha VM-të që ishin nisur më parë në të automatikisht rindezën në nyjat e tjera, ku kanë kopjet. Nëse një nyje dështon për një kohë të gjatë, fillon rikthimi gradual i tepërtisë, dhe klasteri rikthehet në rezervimin N+1.
Balancimi dhe ruajtja e të dhënave ndodhin në nivelin e magazinës software të vetë SimpliVity.
Makinat virtuale fillojnë klasterin e virtualizimit, ai gjithashtu i vendos ata në magazinën software. Vetëm tavolinat u morën sipas një template të zakonshëm: për test u përdorën tavolinat e financistëve dhe operacionistëve (kjo është dy template të ndryshme).
Testimi
Për zhvillimin e testeve u përdor kompleksi testuesit LoginVSI 4.1. Kompleksi LoginVSI përfshin një server menaxhues dhe 12 makina për lidhjet testuese që u vendosën në një host fizik të veçantë.
Testimi u realizua në tre mënyra:
Mënyra Benchmark — variacione ngarkese 300 Knowledge workers dhe 300 Storage workers.
Mënyra Standarde — variacione ngarkese 300 Power workers.
Për të lejuar punën e Power workers dhe për të rritur larmishmërinë e ngarkesës, në kompleks LoginVSI u shtua biblioteka e skedarëve shtesë Power Library. Për të siguruar përshtatshmërinë e rezultateve, të gjitha konfigurimet e testimit janë lënë Default.
Testet e Knowledge dhe Power workers imitojnë ngarkesën reale të përdoruesve që punojnë në stacione virtuale.
Testi Storage workers është krijuar posaçërisht për testimin e sistemeve të ruajtjes të dhënash, është shumë larg ngarkesave reale dhe përbëhet kryesisht nga puna e përdoruesit me shumë skedare të madhësive të ndryshme.
Gjatë testimit, përdoruesit hyjnë në stacionet e punës për rreth 48 minuta, afërsisht një përdorues çdo 10 sekonda.
Rezultatet
Rezultati kryesor i testimit LoginVSI është metrika VSImax, e cila është formuar nga koha e kryerjes së detyrave të ndryshme të lançuara nga përdoruesi. Për shembull: koha e hapjes së një skedari në shënues, koha e kompresimit të një skedari në 7-Zip etj.
Përshkrimi i detajuar i llogaritjes së metrikeve është i disponueshëm në dokumentacionin zyrtar të .
Në terma të tjerë, LoginVSI përsërit një model të zakonshëm ngarkese, duke simuluar veprimet e përdoruesit në paketat e zyrës, gjatë leximit të PDF-ve dhe kështu me radhë, dhe mat vonesat e ndryshme. Ka një nivel kritik vonesash "gjithçka është ngadalësuar, nuk është e mundur të punohet"; deri në arritjen e të cilit konsiderohet se nuk është arritur numri maksimal i përdoruesve. Nëse koha e përgjigjes është më e shpejtë se 1,000 ms se kjo gjendje "gjithçka është ngadalësuar", atëherë sistemi konsiderohet se po punon normalisht dhe mund të shtohen më shumë përdorues.
Këtu janë metrikat kryesore:
Metrika
Veprimet e kryera
Përshkrimi përshkrimi
Komponentët e ngarkuar
NSLD
Koha e hapjes së një
skedari tekstual me madhësi 1,500 KB
Kryhet procedura e hapjes dhe
hapet një dokument rastësor me madhësi 1,500 KB, i kopjuar nga pooli
i burimeve
CPU dhe I/O
NFO
Koha e hapjes së dritares
në Notepad
Hapja e skedarit VSI-Notepad [Ctrl+O]
CPU, RAM dhe I/O
ZHC*
Koha e krijimit të një skedari Zip me kompresim të lartë
Kompresimi i një skedari lokal
rastësor në formatin .pst me madhësi 5MB, i kopjuar nga
pooli i burimeve
CPU dhe I/O
ZLC*
Koha e krijimit të një skedari Zip me kompresim të ulët
Kompresimi i një skedari lokal
rastësor në formatin .pst me madhësi 5MB, i kopjuar nga
pooli i burimeve
I/O
CPU
Llogaritja e një
grupe të madhe të të dhënave rastësore
Krijimi i një grupi të madh
të të dhënave rastësore që do të përdoren në një timer I/O
CPU
Gjatë testimit, së pari llogaritet metrika bazë VSIbase, e cila tregon shpejtësinë e ekzekutimit të detyrave pa ngarkesë në sistem. Në bazë të saj, përcaktohet VSImax Threshold, i cili është i barabartë me VSIbase + 1,000 ms.
Përfundimet për performancën e sistemit nxirren nga dy metrika: VSIbase, e cila përcakton shpejtësinë e funksionimit të sistemit, dhe VSImax threshold, e cila përcakton numrin maksimal të përdoruesve që sistemi mund të mbajë pa degradim të ndjeshëm.
300 benchmark për punonjësit e dijes
Punonjësit e dijes janë përdorues që ngarkojnë rregullisht memorie, procesor dhe I/O me kulme të vogla. Softi emulon ngarkesën e përdoruesve zyrtarë të kërkesave të larta, sikur ata të ishin vazhdimisht duke klikuar në diçka (PDF, Java, paketën e zyrës, shikimin e fotografive, 7-Zip). Me shtimin e përdoruesve nga 0 në 300, vonesa e secilit rritet gradualisht.
Të dhënat statistikore të VSImax:
VSIbase = 986 ms, siç nuk është arritur threshold-i VSI.
Statistikat e ngarkesës në sistemin e ruajtjes nga monitorimi SimpliVity:
Me këtë lloj ngarkese, sistemi përballon rritjen e ngarkesës praktikisht pa degradim të performancës. Koha e ekzekutimit të detyrave të përdoruesve rritet gradualisht, koha e përgjigjes së sistemit nuk ndryshon gjatë testimit dhe është deri në 3 ms për shkarkim dhe deri në 1 ms për lexim.
Dalja: 300 përdorues të dijes punojnë pa asnjë problem në klasterin aktual dhe nuk pengojnë njëri-tjetrin, duke arritur një normë të nënshkrimit pCPU/vCPU 1 me 6. Vonësat totale rriten me rritjen e ngarkesës, por nuk është arritur ndonjë kufi i biznesit.
300 benchmark për punonjësit e ruajtjes
Këta janë përdorues që vazhdimisht shkruajnë dhe lexojnë në një raport prej 30 në 70 përkatësisht. Ky test u krye më shumë për eksperimentim. Të dhënat statistikore të VSImax:
VSIbase = 1673, threshold-i VSI arriti në 240 përdorues.
Statistikat e ngarkesës në sistemin e ruajtjes nga monitorimi SimpliVity:
Ky lloj ngarkese, në thelb, është një test stresi për sistemin e ruajtjes. Gjatë tij, çdo përdorues shkruan në disk një sasi të madhe skedare rastësore të madhësive të ndryshme. Në këtë rast, është e qartë se, kur tejkalohet një prag i caktuar ngarkese, një pjesë e përdoruesve përjetojnë një rritje në kohën e ekzekutimit të detyrave për shkarkimin e skedarëve. Ndërsa ngarkesa në sistemin e ruajtjes, procesorin dhe memorien e hostëve nuk ndryshon ndjeshëm, kështu që aktualisht nuk është e mundur të përcaktosh se me çfarë lidhen vonesat.
Përfundimet për performancën e sistemit me këtë test mund të nxirren vetëm në krahasim me rezultatet e testeve në sisteme të tjera, sepse këto ngarkesa janë sintetike, jo realiste. Megjithatë, në përgjithësi, testi kaloi mirë. Deri në 210 seanca gjithçka shkonte mirë, dhe më pas filluan vonesat e pasqartë, të cilat në këtë rast nuk u monitoruan askund, përveç në Login VSI.
300 punonjës të fuqishëm
Këta janë përdorues që preferojnë CPU-në, memorjen dhe IO të larta. Këta "përdorues të avancuar" e realizojnë rregullisht detyra komplekse me kulme të gjata, si për shembull instalimi i software të ri dhe nxjerrja e skedarëve të mëdhenj. Të dhënat statistikore të VSImax:
VSIbase = 970, threshold-i VSI nuk është arritur.
Statistikat e ngarkesës në sistemin e ruajtjes nga monitorimi SimpliVity:
Gjatë testimit, u arrit një prag ngarkese për procesorët në një nga nyjat e sistemit, por kjo nuk kishte ndikim të ndjeshëm në funksionimin e tij:
Në këtë rast, sistemi përballon rritjen e ngarkesës gjithashtu pa degradim të ndjeshëm të performancës. Koha e ekzekutimit të detyrave të përdoruesve rritet ngadalë, koha e përgjigjes së sistemit nuk ndryshon gjatë testimit dhe është deri në 3 ms për shkarkim dhe deri në 1 ms për lexim.
Testet e zakonshme nuk ishin të mjaftueshme për klientin, dhe ne shkuam më tej: rritëm karakteristikat e VM (numrin e vCPU, për të vlerësuar rritjen e mbipërgjegjësisë dhe madhësinë e diskut) dhe shtuam ngarkesa të tjera.
Gjatë kryerjes së testeve shtesë u përdor konfigurimi i mëposhtëm të standit:
U zhvilluan 300 desktop virtualë në konfigurim 4vCPU, 4GB RAM, 80GB HDD.
Konfigurimi i një nga makinave testuese:
Makinat u zhvilluan në variantin Dedicated – Full Copy:
300 benchmark për punëtorë të njohur me mbipërgjegjësi 12
Të dhënat statistikore të VSImax:
VSIbase = 921 ms, nuk u arrit threshold-i i VSI.
Statistikat e ngarkesës në sistemin e ruajtjes nga monitorimi SimpliVity:
Rezultatet e marra janë të ngjashme me testimin e konfigurimit të mëparshëm të VM.
300 punëtorë të fuqishëm me mbipërgjegjësi 12
Të dhënat statistikore të VSImax:
VSIbase = 933, nuk u arrit threshold-i i VSI.
Statistikat e ngarkesës në sistemin e ruajtjes nga monitorimi SimpliVity:
Gjatë këtij testimi gjithashtu u arrit pragun e ngarkesës së procesorëve, por kjo nuk kishte ndonjë efekt të rëndësishëm në performancë:
Rezultatet e marra janë të ngjashme me testimin e konfigurimit të mëparshëm.
Çfarë do të ndodhte nëse do të startonim ngarkesën për 10 orë?
Tani shohim nëse do të ketë "efekt akumulimi", dhe lëmë testet të funksionojnë për 10 orë rresht.
Testet e gjata dhe përshkrimi i seksionit duhet të jenë të fokusuar në atë që kemi dashur të verifikojmë, nëse do të shfaqen ndonjë problem me fermën nën ngarkesë të gjatë.
300 benchmark për punëtorë të njohur + 10 orë
Për më tepër, u krye një testim i variantit të ngarkesës 300 punëtorë të njohur me punën e përdoruesve gjatë 10 orëve.
Të dhënat statistikore të VSImax:
VSIbase = 919 ms, nuk u arrit threshold-i i VSI.
Të dhënat e statistikave VSImax Detajuar:
Nga grafiku duket se gjatë gjithë testit nuk ka ndonjë degradim të performancës.
Statistikat e ngarkesës në sistemin e ruajtjes nga monitorimi SimpliVity:
Performanca e sistemit të ruajtjes mbetet në të njëjtin nivel gjatë gjithë testit.
Testim shtesë me shtimin e ngarkesës sintetike
Klienti kërkoi të shtohej ngarkesë të madhe në disk. Për këtë, në sistemin e ruajtjes, në secilën nga makinat virtuale të përdoruesve u shtua një detyrë për të aktivizuar ngarkesën sintetike në disk me hyrjen e përdoruesit në sistem. Ngarkesa u sigurua nga utilitarin fio, i cili mundëson kufizimin e ngarkesës në disk sipas numrit të IOPS. Në secilën makinë u aktivizua detyra për të aktivizuar ngarkesën shtesë në numrin 22 IOPS 70 %/30 % Lexim/Shkrim të rastësishëm.
300 benchmark për punëtorë të njohur + 22 IOPS për përdorues
Gjatë testimit fillestar u vërejt se fio krijon një ngarkesë të konsiderueshme shtesë në procesorin e makinave virtuale. Kjo çoi në mbingarkimin e shpejtë të hosteve për CPU dhe ndikoi ndjeshëm në funksionimin e sistemit në përgjithësi.
Ngarkesa në CPU të hosteve:
Vonimet e sistemit të ruajtjes gjithashtu u rritën përkatësisht:
Mungesa e fuqisë përpunuese u bë kritike rreth 240 përdoruesve:
Si pasojë e rezultateve të marra, u vendos të kryhet një testim që ngarkon më pak CPU.
230 benchmark për punëtorë zyre + 22 IOPS për përdorues
Për të reduktuar ngarkesën në CPU u zgjodh lloji i ngarkesës për punëtorët zyre, dhe për çdo sesion u shtuan gjithashtu 22 IOPS ngarkesë sintetike.
Testi u kufizua në 230 sesi për të mos e tejkaluar ngarkesën maksimale në CPU.
Testi u startua me punën e vazhdueshme të përdoruesve për 10 orë për të verifikuar stabilitetin e sistemit gjatë punës me ngarkesë afër maksimales.
Të dhënat statistikore të VSImax:
VSIbase = 918 ms, nuk u arrit threshold-i i VSI.
Të dhënat e statistikave VSImax Detajuar:
Nga grafiku duket se gjatë gjithë testit nuk ka ndonjë degradim të performancës.
Të dhënat e statistikave mbi ngarkesën në CPU:
Gjatë kryerjes së këtij testi, ngarkesa në CPU të hosteve ishte praktikisht maksimale.
Statistikat e ngarkesës në sistemin e ruajtjes nga monitorimi SimpliVity:
Performanca e sistemit të ruajtjes mbetet në të njëjtin nivel gjatë gjithë testit.
Ngarkesa në sistemin e ruajtjes gjatë testit ishte rreth 6 500 IOPS në raportin 60/40 (3 900 IOPS — për lexim, 2 600 IOPS — për shkrim), që është rreth 28 IOPS për çdo stacion pune.
Koha e përgjigjes në mesatare ishte 3 ms për shkrim dhe deri në 1 ms — për lexim.
Përfundimi
Gjatë modelimit të ngarkesave reale në infrastrukturën HPE SimpliVity, u arritën rezultate që konfirmuan aftësinë e sistemit për të mbështetur punën e 300 makinave Full Clone në një çift node SimpliVity. Ndërkohë, koha e përgjigjes së sistemit të ruajtjes u mbajt në nivel optimal gjatë gjithë testimit.
Na na emocionohet shumë qasja për provat e gjata dhe krahasimin e zgjidhjeve para implementimit. Ne mund të testojmë performancën edhe për ngarkesat tuaja, nëse dëshironi. Përfshihet edhe në zgjidhje të tjera hiper-konverguese. Klienti i përmendur aktualisht po përfundon testet në një zgjidhje tjetër paralelisht. Infrastrukturë e tij aktuale është thjesht një grup PC-sh, një domain dhe software në çdo vend pune. Të kalosh në VDI pa teste, natyrisht, është mjaft e vështirë. Është veçanërisht e ndërlikuar të kuptohet potenciali real i fermës VDI, pa migruar përdorues realë në të. Dhe këto teste lejojnë të vlerësohet shpejt potenciali real të një sistemi të caktuar pa pasur nevojë për angazhimin e përdoruesve të zakonshëm. Kështu lindi ky studim.
Qasja e dytë e rëndësishme është se klienti është angazhuar që nga fillimi për një shkallëzim të duhur. Këtu mund të blihen serverë dhe të shtohet një fermë, për shembull, për 100 përdorues, gjithçka parashikohet në mënyrë të qartë për çmimin për përdorues. Për shembull, kur atyre do u nevojitet të shtojnë edhe 300 përdorues, ata do ta dinë se nevojiten dy serverë në një konfiguracion tashmë të caktuar, e jo të rishikojnë mundësitë e modernizimit të infrastrukturës së tyre në përgjithësi.
Më interesojnë mundësitë e federatës HPE SimpliVity. Biznesi është gjeографikisht i shpërndarë, prandaj ka kuptim të vendosësh një pajisje të veçantë VDI në zyrën e largët. Në federatën SimpliVity, çdo virtualizim replikohen sipas një kalendari me mundësinë për të bërë ndërmjet grupeve të shpërndara gjeografikisht shumë shpejt dhe pa ngarkesë në kanal — kjo është një backup i integruar shumë i nivelit të lartë. Gjatë replikimit të VM-ve ndërmjet sitesh, kanali përdoret në mënyrë minimale, sa më shumë që është e mundur, dhe kjo ofron mundësi për të ndërtuar arkitektura shumë interesante DR në prani të një qendre të vetme menaxhimi dhe shumë lokacione të decentralizuara për ruajtje.
E gjithë kjo së bashku ofron mundësinë për të vlerësuar në mënyrë të detajuar anën financiare, dhe të vendosësh kostot për VDI në planet e rritjes së kompanisë, dhe të kuptosh se sa shpejt do të ri-kthehet zgjidhja dhe si do të funksionojë. Sepse çdo VDI është një zgjidhje që në përfundim kursen një sasi të madhe burimesh, por në të njëjtën kohë, me shumë mundësi, pa mundësinë ekonomike të ndryshosh atë brenda 5-7 viteve të përdorimit.
Në përgjithësi, nëse keni pyetje që nuk janë për komente, mos hezitoni të më shkruani në email mk@croc.ru.
Burimi: habr.com
