Klienti deshi VDI. Ai ishte duke e shqyrtuar fort lidhjen SimpliVity + VDI Citrix Virtual Desktop. Për të gjithë operatorët, punonjësit e zyrave në qytete e kështu me radhë. Atje janë pesë mijë përdorues vetëm në valën e parë të migrimit, prandaj ata insistuan mbi testimin e ngarkesës. VDI mund të fillojë të ngadalësojë, mund të bie në gjumë - dhe kjo nuk ndodh gjithmonë për shkak të problemeve me kanalin. Kemi blerë një paketë testimi shumë të fuqishme specifikisht për VDI dhe ngarkuam infrastrukturën derisa ajo ra në disk dhe procesor.
Pra, na nevojitet një shishe plastike, softi LoginVSI për teste të avancuara VDI. Ne e kemi me licenca për 300 përdorues. Pastaj morëm harduerin HPE SimpliVity 380 në konfigurimin më të përshtatshëm për detyrën e maksimizimit të dendësisë së përdoruesve në një server, krijuam makina virtuale me riparim të mirë të shërbimeve, instaluan softin e zyrës në Win10 dhe filluam testimet.
Le të shkojmë!
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 disqeve kryesor: HPE Smart Array P816i-a SR Gen10.
- Disqet e ngurta: 9 x 1.92 TB SATA 6Gb/s SSD (në konfigurimin RAID6 7+2, domethënë kjo është modeli Mesatar në terminologjinë HPE SimpliVity).
- Kartat rrjet: 4 x 1Gb Eth (të dhënat e përdoruesve), 2 x 10Gb Eth (backend SimpliVity dhe vMotion).
- Kartat FPGA të integruara të veçanta në secilën nyje për deduplikimin/përcompressimin.
Nyjet janë të lidhura me njëra-tjetrën përmes interkonnektit 10Gb Ethernet direkt pa një 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ë kluster gjithmonë pasqyrohen midis dy nyjeve.
Nyjet janë bashkuar në një kluster Vmware vSphere nën menaxhimin e vCenter.
Për të realizuar testimin, është instaluar kontrolluesi i domainit dhe brokeri i lidhjes Citrix. Kontrolluesi i domainit, brokeri dhe vCenter janë hequr në një kluster të veçantë.
Si infrastrukturë testimi janë instaluar 300 tavolina virtuale në konfiguracionin Dedicated – Full Copy, domethënë çdo tavolinë virtuale është një kopje e plotë e imazhit origjinal të makinës virtuale dhe ruan të gjitha ndryshimet e bëra nga përdoruesit.
Çdo makinë virtuale ka 2vCPU dhe 4GB RAM:
Në makinat virtuale është 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.
Midishtë nyjeve — replikimi sinkron. Çdo bllok të dhënash në klaster ka dy kopje. Kjo do të thotë se tani ka një set të plotë të dhënash në secilën nga nyjat. Në rastin e një klasteri me tre ose më shumë nyje — kopjet e bllokëve janë në dy vende të ndryshme. Kur krijohet një VM, krijohet një kopje shtesë në njërin nga nyjat e klasterit. Kur një nyje dështuar, të gjithë VM-të që ishin aktivizuar aty automatikisht riaktivizohen në nyje të tjera ku kanë kopje. Nëse një nyje dështoi për një kohë të gjatë, fillon një rikthim gradual i tepërt, dhe klasteri kthehet përsëri në rezervimin N+1.
Balancimi dhe ruajtja e të dhënave ndodhin në nivelin e ruajtjes programore të vetë SimpliVity.
VM-të aktivizojnë klasterin e virtualizimit, e cila gjithashtu i vendos ato në ruajtjen programore. Të njëjtat stacione pune na dhanë modelin tipik: për testim u morën stacionet e punës së financuesve dhe operatorëve (kjo është dy modele të ndryshme).
Testimi
Për kryerjen e testimeve, u përdor kompleksi testues të softuerit LoginVSI 4.1. Kompleksi LoginVSI, i përbërë nga serveri menaxhues dhe 12 makina për lidhje testuese, u vendos në një host fizik të veçantë.
Testimi u krye në tri mënyra:
Mënyra Benchmark — variante ngarkese 300 punonjës të dijes dhe 300 punonjës të ruajtjes.
Mënyra standarde — varianti i ngarkesës 300 punonjësve të fuqishëm.
Për mundësimin e punës së punonjësve të fuqishëm dhe rritjen e variacionit të ngarkesës, në kompleksin LoginVSI u shtua biblioteka e skedarëve të shtesave Power Library. Për të siguruar ripetshmërinë e rezultateve, të gjitha konfigurimet e skenës të testimit u lanë default.
Testet e punonjësve të dijes dhe të fuqishëm simullojnë ngarkesën reale të përdoruesve që punojnë në stacione të virtualizuara.
Testi i punonjësve të ruajtjes është krijuar posaçërisht për testimin e sistemeve të ruajtjes së të dhënave, i largët nga ngarkesat reale dhe kryesisht përbëhet nga puna e përdoruesve me një numër të madh skedarësh me dimensione të ndryshme.
Gjatë testimit, përdoruesit hyjnë në stacionet e punës gjatë 48 minutave, rreth një përdorues çdo 10 sekonda.
Rezultatet
Rezultati kryesor i testimit të LoginVSI është metrika VSImax, e cila përbëhet nga koha e përfundimit të detyrave të ndryshme që kryhen 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ë metrikave është në dokumentacionin zyrtar të .
Në fjalë të tjera, LoginVSI përsërit një shabllon ngarkese tipik, duke simuluar veprimet e përdoruesit në paketën zyrtare, gjatë leximit të PDF-ve dhe të tjera, dhe mat vonesat e ndryshme. Ekziston një nivel kritik vonesash "gjithçka ngadalësohet, punë e paarritshme" deri në arritjen e të cilit konsiderohet se maksimumi i përdoruesve nuk është arritur. Nëse koha e reagimit është më e shpejtë se 1 000 ms se kjo gjendje "gjithçka ngadalësohet", atëherë konsiderohet se sistemi punon normalisht dhe mund të shtohet më shumë përdorues.
Ja metrikat kryesore:
Metrika
Veprimet e prodhuara
Përshkrim i detajuar përshkrim
Komponentët e ngarkuar
NSLD
Koha e hapjes së dokumentit tekstual
me madhësi 1 500 Kbyte
Hapet Notepad dhe
hap një dokument rastësor me madhësi 1 500 Kbyte, i cili është kopjuar nga grumbulli
i burimeve
CPU dhe I/O
NFO
Koha e hapjes së dritares së dialogut
Hapja e skedarit VSI-Notepad [Ctrl+O]
CPU, RAM dhe I/O
ZHC*
Koha e krijimit të një skedari Zip me komprimim të fortë
Kompresimi i një
skedari rastësor të formatit .pst me madhësi 5MB, i cili është kopjuar nga
grumbulli i burimeve
ZLC*
CPU dhe I/O
Koha e krijimit të një skedari Zip me komprimim të dobët
I/O
skedari rastësor të formatit .pst me madhësi 5MB, i cili është kopjuar nga
grumbulli i burimeve
ZLC*
Kalkulimi i një
CPU
array-i të madh të të dhënave rastësore
Krijimi i një array-i të madh të të dhënave rastësore, të cilat do të përdoren në një timer të I/O (I/O-timer)
Gjatë testimit, fillimisht llogaritet metrika bazë VSIbase, e cila tregon shpejtësinë e kryerjes së detyrave pa ngarkesë në sistem. Në bazë të saj përcaktohet pragu VSImax, i cili është e barabartë me VSIbase + 1 000ms.
Konkluzionet mbi performancën e sistemit bëhen mbi bazën e dy metrikeve: VSIbase, e cila përcakton shpejtësinë e punës së sistemit, dhe pragu VSImax, i cili përcakton numrin maksimal të përdoruesve që do të përballojë sistemi pa degradim të rëndësishëm.
CPU
300 benchmark për punonjësit e ditur
Punonjësit e ditur janë përdorues që ngarkojnë rregullisht memorie, procesor dhe I/O me pika të vogla. Programi simulohet ngarkesën e përdoruesve të kërkesave të larta zyrtare, siç janë ata që vazhdimisht klikojnë në diçka (PDF, Java, paketë zyrtare, shikim fotografish, 7-Zip). Me shtimin e përdoruesve nga zero deri në 300, vonesa për çdo përdorues rritet gradualisht.
Të dhënat e statistikave VSImax:
VSIbase = 986ms, pragu VSI nuk është arritur.
Statistika e ngarkesës në sistemin e ruajtjes nga monitorimi SimpliVity:
VSIbase = 986ms, threshold-i VSI nuk është arritur.
Statistikat e ngarkesës në sistemin e ruajtjes nga monitorimi SimpliVity:
Me këtë lloj ngarkese, sistemi përballon rritjen e ngarkesës pothuajse pa degraduar performancën. Koha e ekzekutimit të detyrave nga përdoruesit rritet gradualisht, koha e përgjigjes së sistemit nuk ndryshon gjatë testimit dhe arrin deri në 3 ms për shkruarje dhe deri në 1 ms për lexim.
Përfundimi: 300 përdorues të njohurive funksionojnë pa asnjë problem në klasën aktuale dhe nuk pengojnë njëri-tjetrin, duke arritur një ribllokim pCPU/vCPU 1 me 6. Në përgjithësi, vonesat gjatë rritjes së ngarkesës rriten në mënyrë të barabartë, por kufiri i përcaktuar nuk është arritur.
300 benchmark punonjësish për ruajtje
Këta janë përdorues që vazhdimisht shkruajnë dhe lexojnë në një raport 30 me 70 përkatësisht. Ky test u krye më shumë për eksperiment. Të dhënat e statistikave VSImax:
VSIbase = 1673, kufiri VSI është arritur me 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ë kryerjes së tij, çdo përdorues shkruan në disk një sasi të madhe skedarësh të rastësishëm me përmasa të ndryshme. Në këtë rast, vërehet se, pas kalimit të një pragu të caktuar ngarkese, për disa përdorues rritet koha e ekzekutimit të detyrave për shkruarje skedarësh. Megjithatë, ngarkesa në sistemin e ruajtjes, procesorin dhe memorien e hosteve nuk ndryshon ndjeshëm, prandaj nuk është e mundur të përcaktohet saktësisht se me çfarë lidhen vonesat për momentin.
Mund të bëhen përfundime për performancën e sistemit me këtë test vetëm në krahasim me rezultatet e testeve në sisteme të tjera, pasi këto ngarkesa janë sintetike, jo realiste. Megjithatë, në përgjithësi, testi kaloi mirë. Deri në 210 seanca gjithçka shkoi mirë, dhe më pas filluan përgjigjet e paqartë, të cilat ndërkohë nuk u monitoruan askund tjetër përveç Login VSI.
300 punonjësish të fuqishëm
Këta janë përdorues që preferojnë procesorin, memorien dhe IO të lartë. Këta "përdorues të avancuar" rregullisht kryejnë detyra komplekse me pika të gjata si instalimi i softuerit të ri dhe zhbllokimi i arkivave të mëdha. Të dhënat e statistikave VSImax:
VSIbase = 970, kufiri VSI nuk është arritur.
Statistikat e ngarkesës në sistemin e ruajtjes nga monitorimi SimpliVity:
Gjatë testimit, u arrit kufiri i ngarkesës së procesorëve në njërin nga nyjet e sistemit, por kjo nuk ndikoi ndjeshëm në funksionimin e saj:
Në këtë rast, sistemi përballon rritjen e ngarkesës gjithashtu pa një degradim të rëndësishëm të performancës. Koha e ekzekutimit të detyrave të përdoruesve rritet gradualisht, koha e përgjigjes së sistemit nuk ndryshon gjatë testimit dhe arrin deri në 3 ms për shkrim dhe deri në 1 ms për lexim.
Testet standarde nuk ishin të mjaftueshme për klientin, kështu që shkuam më tej: rritëm karakteristikat e VM-së (numri i vCPU-ve, për të vlerësuar rritjen e mbivendosjes dhe madhësinë e diskut) dhe shtuam një ngarkesë të shtuar.
Gjatë kryerjes së testeve shtesë u përdor konfigurimi në vazhdim:
Janë përcaktuar 300 stola virtualë të punës në konfigurimin 4vCPU, 4GB RAM, 80GB HDD.
Konfigurimi i një prej makinave testuese:
Makinat janë vendosur në variantin Dedicated – Full Copy:
300 teste të punonjësve të dijes me mbivendosje 12
Statistika e ngarkesës në sistemin e ruajtjes nga monitorimi SimpliVity:
VSIbase = 921 ms, VSI Threshold nuk u arrit.
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-së.
300 teste të punonjësve energjikë me mbivendosje 12
Statistika e ngarkesës në sistemin e ruajtjes nga monitorimi SimpliVity:
VSIbase = 933, VSI Threshold nuk u arrit.
Statistikat e ngarkesës në sistemin e ruajtjes nga monitorimi SimpliVity:
Gjatë këtij testimi gjithashtu u arrit kufiri i ngarkesës së procesorëve, por kjo nuk pati ndikim të madh në performancë:
Rezultatet e marra janë të ngjashme me testimin e konfigurimit të mëparshëm.
Çfarë do të ndodhë nëse drejtojmë ngarkesën për 10 orë?
Tani shohim nëse do të ketë "efekt akumulimi", dhe fillojmë testet për 10 orë rresht.
Testet e gjata dhe përshkrimi i seksionit duhet të jenë të orientuara drejt asaj që donim të kontrollonim, nëse do të shfaqeshin ndonjë problem me fermën gjatë ngarkesës së gjatë mbi të.
300 teste të punonjësve të dijes + 10 orë
Përveç kësaj, u zhvillua një testim i ngarkesës nga 300 punonjës të dijes me punë të vazhdueshme për 10 orë.
Statistika e ngarkesës në sistemin e ruajtjes nga monitorimi SimpliVity:
VSIbase = 919 ms, VSI Threshold nuk u arrit.
Të dhënat statistikore VSImax Detajuar:
Nga grafiku shihet 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 një ngarkese sintetike
Klienti kërkoi të shtonte një 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 kur përdoruesi hynte në sistem. Ngarkesa sigurohej nga utilitari fio, i cili lejon të kufizohej ngarkesa në disk sipas numrit të IOPS. Në secilën makinë, u aktivizua një detyrë për të nisur ngarkesë shtesë me 22 IOPS 70%/30% Lexim/Ruajtje Rashtazi.
300 Përdorues të njohur + 22 IOPS për përdorues
Gjatë testit fillestar u zbulua se fio krijon një ngarkesë të konsiderueshme shtesë në procesorin e makinave virtuale. Kjo çoi në një mbingarkesë të shpejtë të hosteve sipas CPU-së dhe ndikoi shumë në funksionimin e sistemit si një e tërë.
Ngarkesa në CPU-në e hosteve:
Voncat e sistemit të ruajtjes gjithashtu u rritën përkatësisht:
Mungesa e fuqisë përpunuese u bë kritike pas rreth 240 përdoruesve:
Si rezultat i rezultateve të marra, u vendos të kryhej një testim që ngarkon më pak CPU-në.
230 Përdorues të zyrës + 22 IOPS për përdorues
Për të ulur ngarkesën në CPU, u zgjodh lloji i ngarkesës së Përdoruesve të Zyrës, në çdo seancë u shtua gjithashtu 22 IOPS ngarkesë sintetike.
Testi u kufizua në 230 seanca për të mos tejkaluar ngarkesën maksimale në CPU.
Testi u aktivizua me punën e vazhdueshme të përdoruesve për 10 orë për të kontrolluar stabilitetin e sistemit gjatë një periudhe të gjatë pune me një ngarkesë të afërt me maksimale.
Statistika e ngarkesës në sistemin e ruajtjes nga monitorimi SimpliVity:
VSIbase = 918 ms, VSI Thrshold nuk u arrit.
Të dhënat statistikore VSImax Detajuar:
Nga grafiku shihet se gjatë gjithë testit nuk ka ndonjë degradim të performancës.
Të dhënat statistikore për ngarkesën në CPU:
Gjatë ekzekutimit të këtij testi, ngarkesa në CPU-në e 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 me një raport 60/40 (3,900 IOPS për lexim, 2,600 IOPS për shkrim), që jep 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
Në modelimin e ngarkesave reale në infrastrukturën HPE SimpliVity, u arritën rezultate që konfirmojnë kapacitetin e sistemit për të mbështetur funksionimin e makinave virtuale të punës me numër jo më pak se 300 Full Clone në dy node SimpliVity. Në të njëjtën kohë, koha e përgjigjes së sistemit të ruajtjes u mbajt në nivele optimale gjatë gjithë testimit.
Na na pëlqen shumë qasja për testet e gjata dhe krahasimin e zgjidhjeve përpara zbatimit. Ne mund të testojmë performancën edhe për ngarkesat tuaja, nëse dëshironi. Po ashtu, në zgjidhje të tjera hiperkonverguese. Klienti i përmendur tani është duke përfunduar testet në një zgjidhje tjetër në paralel. Infrastruktura e tij aktuale është thjesht një park kompjuterësh, domain dhe software në çdo vend pune. Të kalosh te VDI pa teste, sigurisht, është mjaft e vështirë. Konkretisht, është e vështirë të kuptosh aftësitë reale të fermës VDI, pa migruar përdorues realë në të. Dhe këto teste lejojnë të vlerësohet shpejt efiçenca reale e një sistemi pa pasur nevojë për angazhimin e përdoruesve normalë. Këtu ka lindur një studim i tillë.
Qasja e dytë e rëndësishme është që klienti në fillim ka parashikuar një skalim të duhur. Këtu mund të blejë një server dhe të shtojë një fermë, për shembull, për 100 përdorues, e gjithë kjo parashikohet në çmim për përdorues. Për shembull, kur atyre u nevojitet të shtojnë edhe 300 përdorues, ata do të dinë se nevojiten dy serverë në një konfigurim tashmë të përcaktuar, e jo të rishikojnë mundësitë e modernizimit të infrastrukturës së tyre në tërësi.
Më interesojnë mundësitë e federatës HPE SimpliVity. Biznesi është gjeografikisht i ndarë, prandaj ka kuptim të vendosësh një pajisje të veçantë VDI në zyrën e largët. Në federatën SimpliVity, çdo virtualizim riplikohet sipas një orari me mundësinë për të bërë midis klasterëve gjeografikisht të largët shumë shpejt dhe pa ngarkesë në kanal - ky është një backup i integruar në një nivel shumë të shkëlqyer. Gjatë riplikimit të VM-ve midis vendeve, kanali përdoret në mënyrën më minimale të mundshme, dhe kjo ofron mundësi për ndërtimin e arkitekturave shumë interesante të DR në prani të një qendre të vetme menaxhimi dhe shumë vendeve decentralizuara të ruajtjes.
E gjitha kjo në bashkëpunim ofron mundësinë për të vlerësuar edhe anën financiare në mënyrë shumë të detajuar, dhe për të vendosur shpenzimet për VDI mbi planet e rritjes së kompanisë, dhe për të kuptuar se sa shpejt do të kthehet zgjidhja dhe si do të funksionojë. Sepse çdo VDI është një zgjidhje që në fund kursen një masë të madhe burimesh, por në të njëjtën kohë, ka të ngjarë të mos ofrojë një mundësi ekonomikisht të favorshme për ta ndërruar atë brenda 5-7 vjetëve të përdorimit.
Në përgjithësi, nëse keni pyetje që nuk janë për komente, — më shkruani në email mk@croc.ru.
Burimi: habr.com
