Klienti donte VDI. Vështrova vërtet kombinimin SimpliVity + VDI Citrix Virtual Desktop. Për të gjithë operatorët, punonjësit e zyrës së qytetit, e kështu me radhë. Vetëm në valën e parë të migrimit janë pesë mijë përdorues dhe për këtë arsye ata insistuan në testimin e ngarkesës. VDI mund të fillojë të ngadalësohet, mund të shtrihet me qetësi - dhe kjo nuk ndodh gjithmonë për shkak të problemeve me kanalin. Ne blemë një paketë testimi shumë të fuqishme posaçërisht për VDI dhe ngarkuam infrastrukturën derisa ishte shumë e rëndë në disqe dhe procesor.
Pra, do të na duhet një shishe plastike dhe softuer LoginVSI për teste të sofistikuara VDI. E kemi me licenca për 300 përdorues. Më pas morëm harduerin HPE SimpliVity 380 në një paketë të përshtatshme për detyrën e densitetit maksimal të përdoruesit për server, premë makinat virtuale me mbiabonim të mirë, instaluam softuerin e zyrës në Win10 mbi to dhe filluam testimin.
Le të shkojë!
Sistem
Dy nyje (server) HPE SimpliVity 380 Gen10. Ne secilen:
- 2 x Intel Xeon Platinum 8170 26c 2.1 Ghz.
- RAM: 768 GB, 12 x 64 GB LRDIMM DDR4 2666 MHz.
- Kontrolluesi kryesor i diskut: HPE Smart Array P816i-a SR Gen10.
- Disqet e ngurtë: 9 x 1.92 TB SATA 6 Gb/s SSD (në konfigurimin RAID6 7+2, d.m.th. ky është një model i mesëm në termat HPE SimpliVity).
- Kartat e rrjetit: 4 x 1 Gb Eth (të dhënat e përdoruesit), 2 x 10 Gb Eth (SimpliVity dhe vMotion backend).
- Kartat speciale të integruara FPGA në secilën nyje për dedublikim/kompresim.
Nyjet janë të lidhura me njëra-tjetrën nëpërmjet një ndërlidhjeje Ethernet 10 Gb drejtpërdrejt pa një ndërprerës të jashtëm, i cili përdoret si një bazë mbështetëse SimpliVity dhe për transferimin e të dhënave të makinës virtuale nëpërmjet NFS. Të dhënat e makinës virtuale në një grup pasqyrohen gjithmonë midis dy nyjeve.
Nyjet kombinohen në një grup Vmware vSphere të menaxhuar nga vCenter.
Për testim, u vendosën një kontrollues domeni dhe një ndërmjetës i lidhjes Citrix. Kontrolluesi i domenit, ndërmjetësi dhe vCenter vendosen në një grup të veçantë.
Si një infrastrukturë testimi, 300 desktop virtual u vendosën në konfigurimin Dedicated – Full Copy, d.m.th., çdo desktop ë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 4 GB RAM:
Softueri i mëposhtëm i kërkuar për testim u instalua në makinat virtuale:
- Windows 10 (64-bit), versioni 1809.
- Adobe Reader XI.
- Citrix Virtual Delivery Agent 1811.1.
- Doro PDF 1.82.
- Përditësimi i Java 7 13.
- Microsoft Office Professional Plus 2016.
Midis nyjeve - riprodhimi sinkron. Çdo bllok i të dhënave në grup ka dy kopje. Kjo do të thotë, tani ekziston një grup i plotë i të dhënave për secilën prej nyjeve. Me një grup prej tre ose më shumë nyjeve, kopjet e blloqeve janë në dy vende të ndryshme. Kur krijoni një VM të ri, krijohet një kopje shtesë në një nga nyjet e grupimit. Kur një nyje dështon, të gjitha VM-të që funksiononin më parë në të rinisen automatikisht në nyjet e tjera ku ato kanë kopje. Nëse një nyje dështon për një kohë të gjatë, atëherë fillon restaurimi gradual i tepricës dhe grupi kthehet në tepricë N+1.
Balancimi dhe ruajtja e të dhënave ndodh në nivelin e ruajtjes së softuerit të vetë SimpliVity.
Makinat virtuale drejtojnë një grup virtualizimi, i cili gjithashtu i vendos ato në ruajtjen e softuerit. Vetë tavolinat u morën sipas një modeli standard: tavolinat e financuesve dhe oficerëve të operacioneve erdhën për provë (këto janë dy shabllone të ndryshëm).
Testimi
Për testim, u përdor paketa testuese e softuerit LoginVSI 4.1. Kompleksi LoginVSI, i përbërë nga një server kontrolli dhe 12 makina për lidhjet e testimit, u vendosën në një host fizik të veçantë.
Testimi u krye në tre mënyra:
Modaliteti i standardit - ngarkesa 300 punëtorë të njohurive dhe 300 punëtorë të ruajtjes.
Modaliteti standard - kuti ngarkese 300 Punonjësit e energjisë.
Për të mundësuar punën e punëtorëve të Power dhe për të rritur diversitetin e ngarkesës, një bibliotekë me skedarë shtesë të Power Library u shtua në kompleksin LoginVSI. Për të siguruar përsëritshmërinë e rezultateve, të gjitha cilësimet e stolit të testimit u lanë si të parazgjedhura.
Testet e punëtorëve të njohurive dhe fuqisë simulojnë ngarkesën reale të përdoruesve që punojnë në stacione pune virtuale.
Testi i punëtorëve të ruajtjes u krijua posaçërisht për testimin e sistemeve të ruajtjes së të dhënave; ai është larg nga ngarkesat reale të punës dhe kryesisht përfshin përdoruesin që punon me një numër të madh skedarësh të madhësive të ndryshme.
Gjatë testimit, përdoruesit hyjnë në stacionet e punës për 48 minuta me një shpejtësi prej afërsisht një përdorues çdo 10 sekonda.
Gjetjet
Rezultati kryesor i testimit LoginVSI është metrika VSImax, e cila është përpiluar nga koha e ekzekutimit të detyrave të ndryshme të nisura nga përdoruesi. Për shembull: koha për të hapur një skedar në Notepad, koha për të kompresuar një skedar në 7-Zip, etj.
Një përshkrim i detajuar i llogaritjes së metrikës është i disponueshëm në dokumentacionin zyrtar për .
Me fjalë të tjera, LoginVSI përsërit një model tipik ngarkimi, duke simuluar veprimet e përdoruesit në një suitë zyre, duke lexuar një PDF, e kështu me radhë, dhe mat vonesat e ndryshme. Ekziston një nivel kritik i vonesave "gjithçka ngadalësohet, është e pamundur të punohet"), para së cilës konsiderohet se nuk është arritur numri maksimal i përdoruesve. Nëse koha e përgjigjes është 1 ms më e shpejtë se kjo gjendje "gjithçka është e ngadaltë", atëherë sistemi konsiderohet se funksionon normalisht dhe mund të shtohen më shumë përdorues.
Këtu janë metrikat kryesore:
Metrikat
Veprimet e marra
I detajuar описание
Komponentët e ngarkuar
N.S.L.D.
Koha e hapjes së tekstit
skedar me peshë 1 KB
Notepad hapet dhe
hap një dokument të rastësishëm 1 KB që kopjohet nga grupi
të burimeve
CPU dhe I/O
NFO
Ora e hapjes së dialogut
dritaret në bllokun e shënimeve
Hapja e një skedari VSI-Notepad [Ctrl+O]
CPU, RAM dhe I/O
ZHC*
Koha për të krijuar një skedar Zip shumë të ngjeshur
Kompresim lokal
Skedari .pst i rastësishëm 5MB i kopjuar nga
pishina e burimeve
CPU dhe I/O
ZLC*
Koha për të krijuar një skedar Zip të ngjeshur dobët
Kompresim lokal
Skedari .pst i rastësishëm 5MB i kopjuar nga
pishina e burimeve
I / O
CPU
Llogaritja e madhe
grup i rastësishëm i të dhënave
Krijimi i një grupi të madh
të dhëna të rastësishme që do të përdoren në kohëmatësin hyrës/dalës (kohëmatësi I/O)
CPU
Kur kryhet testimi, fillimisht llogaritet metrika bazë VSIbase, e cila tregon shpejtësinë me të cilën ekzekutohen punët pa ngarkesë në sistem. Në bazë të tij përcaktohet pragu VSImax, i cili është i barabartë me VSIbase + 1ms.
Përfundimet në lidhje me performancën e sistemit bëhen bazuar në dy metrika: VSIbase, e cila përcakton shpejtësinë e sistemit, dhe pragu VSImax, i cili përcakton numrin maksimal të përdoruesve që sistemi mund të trajtojë pa degradim të konsiderueshëm.
300 Standardi i punëtorëve të njohurive
Punëtorët e njohurive janë përdorues që ngarkojnë rregullisht memorien, procesorin dhe IO me maja të ndryshme të vogla. Softueri imiton ngarkesën e punës së përdoruesve kërkues të zyrës, sikur ata vazhdimisht po kërkuan diçka (PDF, Java, paketa e zyrës, shikimi i fotografive, 7-Zip). Ndërsa shtoni përdorues nga zero në 300, vonesa për secilin rritet gradualisht.
Të dhënat statistikore të VSImax:
VSIbase = 986ms, Pragu VSI nuk u arrit.
Statistikat e ngarkesës së sistemit të ruajtjes nga monitorimi i SimpliVity:
Me këtë lloj ngarkese, sistemi mund t'i rezistojë rritjes së ngarkesës praktikisht pa degradim në performancë. Koha që duhet për të përfunduar detyrat e përdoruesit rritet pa probleme, koha e përgjigjes së sistemit nuk ndryshon gjatë testimit dhe është deri në 3 ms për shkrim dhe deri në 1 ms për lexim.
Përfundim: 300 përdorues të njohurive punojnë në grupin aktual pa asnjë problem dhe nuk ndërhyjnë me njëri-tjetrin, duke arritur mbi-abonimin pCPU/vCPU nga 1 në 6. Vonesat e përgjithshme rriten në mënyrë të barabartë me rritjen e ngarkesës, por kufiri i përcaktuar nuk është arritur.
Standardi i 300 punëtorëve të magazinimit
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 hir të eksperimentit. Të dhënat statistikore të VSImax:
VSIbase = 1673, Pragu VSI arriti në 240 përdorues.
Statistikat e ngarkesës së sistemit të ruajtjes nga monitorimi i SimpliVity:
Ky lloj ngarkese është në thelb një test stresi i sistemit të ruajtjes. Kur ekzekutohet, çdo përdorues shkruan shumë skedarë të rastësishëm të madhësive të ndryshme në disk. Në këtë rast, mund të shihet se kur një prag i caktuar i ngarkesës tejkalohet për disa përdorues, koha që duhet për të përfunduar detyrat për shkrimin e skedarëve rritet. Në të njëjtën kohë, ngarkesa në sistemin e ruajtjes, procesorin dhe kujtesën e hosteve nuk ndryshon ndjeshëm, kështu që aktualisht është e pamundur të përcaktohet saktësisht se çfarë po shkakton vonesat.
Përfundimet në lidhje me performancën e sistemit duke përdorur këtë test mund të bëhen vetëm në krahasim me rezultatet e testimit në sisteme të tjera, pasi ngarkesa të tilla janë sintetike dhe joreale. Sidoqoftë, në përgjithësi, testi shkoi mirë. Gjithçka shkoi mirë deri në 210 seanca, dhe më pas filluan përgjigjet e çuditshme, të cilat nuk u gjurmuan askund përveç Login VSI.
300 punëtorë të energjisë elektrike
Këta janë përdorues që duan CPU, memorie dhe IO të lartë. Këta "përdorues të fuqishëm" kryejnë rregullisht detyra komplekse me breshëri të gjata, të tilla si instalimi i softuerit të ri dhe shpaketimi i arkivave të mëdha. Të dhënat statistikore të VSImax:
VSIbase = 970, Pragu VSI nuk u arrit.
Statistikat e ngarkesës së sistemit të ruajtjes nga monitorimi i SimpliVity:
Gjatë testimit, pragu i ngarkesës së procesorit u arrit në një nga nyjet e sistemit, por kjo nuk pati një ndikim të rëndësishëm në funksionimin e tij:
Në këtë rast, sistemi mund të përballojë ngarkesë të shtuar pa degradim të ndjeshëm të performancës. Koha që duhet për të përfunduar detyrat e përdoruesit rritet pa probleme, koha e përgjigjes së sistemit nuk ndryshon gjatë testimit dhe është deri në 3 ms për shkrim dhe deri në 1 ms për lexim.
Testet e rregullta nuk ishin të mjaftueshme për klientin dhe shkuam më tej: rritëm karakteristikat e VM (numrin e vCPU-ve për të vlerësuar rritjen e mbiabonimit dhe madhësisë së diskut) dhe shtuam ngarkesë shtesë.
Gjatë kryerjes së testeve shtesë, u përdor konfigurimi i mëposhtëm i stendës:
300 desktop virtual u vendosën në një konfigurim 4vCPU, 4GB RAM, 80GB HDD.
Konfigurimi i njërës prej makinave testuese:
Makineritë vendosen në opsionin Dedicated – Full Copy:
300 Punëtorët e njohurive standarde me mbiabonim 12
Të dhënat statistikore të VSImax:
VSIbase = 921 ms, Pragu VSI nuk u arrit.
Statistikat e ngarkesës së sistemit të ruajtjes nga monitorimi i SimpliVity:
Rezultatet e marra janë të ngjashme me testimin e konfigurimit të mëparshëm VM.
300 punëtorë të energjisë elektrike me 12 mbiabonime
Të dhënat statistikore të VSImax:
VSIbase = 933, Pragu VSI nuk u arrit.
Statistikat e ngarkesës së sistemit të ruajtjes nga monitorimi i SimpliVity:
Gjatë këtij testimi, u arrit edhe pragu i ngarkesës së procesorit, por kjo nuk pati një ndikim të rëndësishëm në performancën:
Rezultatet e marra janë të ngjashme me testimin e konfigurimit të mëparshëm.
Çfarë ndodh nëse e përdorni ngarkesën për 10 orë?
Tani le të shohim nëse do të ketë një "efekt akumulimi" dhe të kryejmë teste për 10 orë rresht.
Testet afatgjata dhe përshkrimi i seksionit duhet të synojnë faktin se ne donim të kontrollonim nëse do të lindte ndonjë problem me këllëfin nën ngarkesë të zgjatur mbi të.
300 punëtorë me njohuri standarde + 10 orë
Përveç kësaj, u testua një rast i ngarkesës prej 300 punëtorësh njohurish, i ndjekur nga puna e përdoruesit për 10 orë.
Të dhënat statistikore të VSImax:
VSIbase = 919 ms, Pragu VSI nuk u arrit.
Të dhëna statistikore të detajuara VSImax:
Grafiku tregon se nuk ka degradim të performancës gjatë gjithë testit.
Statistikat e ngarkesës së sistemit të ruajtjes nga monitorimi i SimpliVity:
Performanca e sistemit të ruajtjes mbetet e njëjtë gjatë gjithë testit.
Prova shtesë me shtimin e ngarkesës sintetike
Klienti kërkoi të shtonte një ngarkesë të egër në disk. Për ta bërë këtë, një detyrë iu shtua sistemit të ruajtjes në secilën nga makinat virtuale të përdoruesit për të ekzekutuar një ngarkesë sintetike në disk kur përdoruesi regjistrohet në sistem. Ngarkesa u sigurua nga programi fio, i cili ju lejon të kufizoni ngarkesën në disk me numrin e IOPS. Në secilën makinë, u lançua një detyrë për të nisur një ngarkesë shtesë në shumën prej 22 IOPS 70%/30% Leximi/Shkrim i rastësishëm.
300 punëtorë me njohuri standarde + 22 IOPS për përdorues
Në testimin fillestar, fio u zbulua se impononte shpenzime të larta të CPU-së në makinat virtuale. Kjo çoi në mbingarkesë të shpejtë të CPU-së të hosteve dhe ndikoi shumë në funksionimin e sistemit në tërësi.
Ngarkesa e CPU-së së hostit:
Në të njëjtën kohë, vonesat e sistemit të ruajtjes gjithashtu u rritën natyrshëm:
Mungesa e fuqisë kompjuterike u bë kritike për rreth 240 përdorues:
Për shkak të rezultateve të marra, u vendos që të kryhej testimi që ishte më pak intensiv i CPU-së.
Standardi i 230 punonjësve të zyrës + 22 IOPS për përdorues
Për të reduktuar ngarkesën në CPU, u zgjodh lloji i ngarkesës së punonjësve të Office dhe në çdo seancë u shtuan gjithashtu 22 IOPS të ngarkesës sintetike.
Testi u kufizua në 230 seanca për të mos tejkaluar ngarkesën maksimale të CPU-së.
Testi u krye me përdoruesit që vraponin për 10 orë për të kontrolluar qëndrueshmërinë e sistemit gjatë funksionimit afatgjatë me ngarkesë afër maksimale.
Të dhënat statistikore të VSImax:
VSIbase = 918 ms, Pragu VSI nuk u arrit.
Të dhëna statistikore të detajuara VSImax:
Grafiku tregon se nuk ka degradim të performancës gjatë gjithë testit.
Statistikat e ngarkesës së CPU-së:
Gjatë kryerjes së këtij testi, ngarkesa në CPU-në e hostit ishte pothuajse maksimale.
Statistikat e ngarkesës së sistemit të ruajtjes nga monitorimi i SimpliVity:
Performanca e sistemit të ruajtjes mbetet e njëjtë gjatë gjithë testit.
Ngarkesa në sistemin e ruajtjes gjatë testit ishte afërsisht 6 IOPS në një raport 500/60 (40 IOPS lexim, 3 IOPS shkrim), që është afërsisht 900 IOPS për stacion pune.
Koha e përgjigjes ishte mesatarisht 3 ms për shkrim dhe deri në 1 ms për lexim.
Total
Gjatë simulimit të ngarkesave reale në infrastrukturën HPE SimpliVity, u morën rezultate që konfirmojnë aftësinë e sistemit për të mbështetur desktopët virtualë të të paktën 300 makinave Full Clone në një palë nyje SimpliVity. Në të njëjtën kohë, koha e përgjigjes së sistemit të ruajtjes u mbajt në një nivel optimal gjatë gjithë testimit.
Ne jemi shumë të impresionuar nga qasja e testimit të gjatë dhe krahasimit të zgjidhjeve përpara zbatimit. Ne mund të testojmë performancën edhe për ngarkesat tuaja të punës nëse dëshironi. Përfshirë zgjidhje të tjera të hiperkonvergjuara. Klienti i përmendur tani është duke përfunduar testet në një zgjidhje tjetër paralelisht. Infrastruktura e saj aktuale është thjesht një flotë PC, një domen dhe softuer në çdo vend pune. Kalimi në VDI pa teste është, natyrisht, mjaft i vështirë. Në mënyrë të veçantë, është e vështirë të kuptohen aftësitë reale të një ferme VDI pa migrimin e përdoruesve të vërtetë në të. Dhe këto teste ju lejojnë të vlerësoni shpejt aftësitë reale të një sistemi të veçantë pa pasur nevojë të përfshini përdorues të zakonshëm. Nga këtu erdhi ky studim.
Qasja e dytë e rëndësishme është që klienti të angazhohet menjëherë për shkallëzimin e duhur. Këtu mund të blini një server shtesë dhe të shtoni një fermë, për shembull, për 100 përdorues, gjithçka është e parashikueshme me çmimin e përdoruesit. Për shembull, kur duhet të shtojnë 300 përdorues të tjerë, ata do të dinë se u duhen dy serverë në një konfigurim të përcaktuar tashmë, në vend që të rishqyrtojnë përmirësimin e të gjithë infrastrukturës së tyre.
Mundësitë e federatës HPE SimpliVity janë interesante. Biznesi është i ndarë gjeografikisht, kështu që ka kuptim të instaloni pajisjen tuaj të veçantë VDI në një zyrë të largët. Në federatën SimpliVity, çdo makinë virtuale riprodhohet sipas një plani me aftësinë për t'u përsëritur midis grupimeve të largëta gjeografikisht shumë shpejt dhe pa ngarkesë në kanal - ky është një kopje rezervë e integruar e një niveli shumë të mirë. Kur përsëriten VM-të ndërmjet sajteve, kanali përdoret sa më minimalisht të jetë e mundur, dhe kjo bën të mundur ndërtimin e arkitekturave DR shumë interesante në prani të një qendre të vetme kontrolli dhe një grupi vendesh ruajtjeje të decentralizuara.
E gjithë kjo së bashku bën të mundur vlerësimin e anës financiare në detaje dhe mbivendosjen e kostove të VDI mbi planet e rritjes së kompanisë dhe për të kuptuar se sa shpejt do të shpërblehet zgjidhja dhe si do të funksionojë. Sepse çdo VDI është një zgjidhje që në fund të fundit kursen shumë burime, por në të njëjtën kohë, ka shumë të ngjarë, pa mundësinë me kosto efektive për ta ndryshuar atë brenda 5-7 viteve të përdorimit.
Në përgjithësi, nëse keni ndonjë pyetje që nuk është për koment, më shkruani me email [email mbrojtur].
Burimi: www.habr.com