Gusto ng customer ng VDI. Talagang tiningnan ko ang kumbinasyon ng SimpliVity + VDI Citrix Virtual Desktop. Para sa lahat ng operator, empleyado ng opisina ng lungsod, at iba pa. Mayroong limang libong mga gumagamit sa unang alon ng paglipat lamang, at samakatuwid ay iginiit nila ang pagsubok sa pagkarga. Maaaring magsimulang bumagal ang VDI, maaari itong mahinahon na humiga - at hindi ito palaging nangyayari dahil sa mga problema sa channel. Bumili kami ng napakalakas na testing package na partikular para sa VDI at ni-load ang imprastraktura hanggang sa maging masyadong mabigat ito sa mga disk at processor.
Kaya, kakailanganin namin ng isang plastic na bote at LoginVSI software para sa mga sopistikadong pagsusuri sa VDI. Mayroon kaming mga lisensya para sa 300 mga gumagamit. Pagkatapos ay kinuha namin ang HPE SimpliVity 380 hardware sa isang pakete na angkop para sa gawain ng maximum na density ng user sa bawat server, pinutol ang mga virtual machine na may mahusay na oversubscription, nag-install ng software ng opisina sa Win10 sa kanila at nagsimulang subukan.
Sabihin pumunta!
Sistema
Dalawang HPE SimpliVity 380 Gen10 node (server). Sa bawat:
- 2 x Intel Xeon Platinum 8170 26c 2.1Ghz.
- RAM: 768GB, 12 x 64GB LRDIMMs DDR4 2666MHz.
- Pangunahing disk controller: HPE Smart Array P816i-a SR Gen10.
- Mga hard drive: 9 x 1.92 TB SATA 6Gb/s SSD (sa RAID6 7+2 configuration, ibig sabihin, ito ay isang Medium na modelo sa mga tuntunin ng HPE SimpliVity).
- Mga network card: 4 x 1Gb Eth (data ng user), 2 x 10Gb Eth (SimpliVity at vMotion backend).
- Mga espesyal na built-in na FPGA card sa bawat node para sa deduplication/compression.
Ang mga node ay konektado sa isa't isa sa pamamagitan ng 10Gb Ethernet interconnect nang direkta nang walang external switch, na ginagamit bilang SimpliVity backend at para sa paglilipat ng data ng virtual machine sa pamamagitan ng NFS. Ang data ng virtual machine sa isang cluster ay palaging naka-mirror sa pagitan ng dalawang node.
Ang mga node ay pinagsama sa isang Vmware vSphere cluster na pinamamahalaan ng vCenter.
Para sa pagsubok, isang domain controller at isang Citrix connection broker ang na-deploy. Ang domain controller, broker at vCenter ay inilalagay sa isang hiwalay na cluster.
Bilang isang pagsubok na imprastraktura, 300 virtual desktop ang na-deploy sa Dedicated – Full Copy configuration, ibig sabihin, ang bawat desktop ay isang kumpletong kopya ng orihinal na larawan ng virtual machine at sine-save ang lahat ng pagbabagong ginawa ng mga user.
Ang bawat virtual machine ay may 2vCPU at 4GB RAM:
Ang sumusunod na software na kinakailangan para sa pagsubok ay na-install sa mga virtual machine:
- Windows 10 (64-bit), bersyon 1809.
- Adobe Reader XI.
- Citrix Virtual Delivery Agent 1811.1.
- Doro PDF 1.82.
- Java 7 Update 13.
- Microsoft Office Professional Plus 2016.
Sa pagitan ng mga node - kasabay na pagtitiklop. Ang bawat data block sa cluster ay may dalawang kopya. Ibig sabihin, ngayon ay may kumpletong hanay ng data sa bawat isa sa mga node. Sa isang kumpol ng tatlo o higit pang mga node, ang mga kopya ng mga bloke ay nasa dalawang magkaibang lugar. Kapag gumagawa ng bagong VM, isang karagdagang kopya ang gagawin sa isa sa mga cluster node. Kapag nabigo ang isang node, ang lahat ng VM na dating tumatakbo dito ay awtomatikong magre-restart sa iba pang mga node kung saan mayroon silang mga replika. Kung nabigo ang isang node sa loob ng mahabang panahon, magsisimula ang unti-unting pagpapanumbalik ng redundancy, at babalik ang cluster sa N+1 redundancy.
Ang pagbabalanse ng data at imbakan ay nangyayari sa antas ng imbakan ng software ng SimpliVity mismo.
Ang mga virtual machine ay nagpapatakbo ng isang virtualization cluster, na inilalagay din ang mga ito sa imbakan ng software. Ang mga mesa mismo ay kinuha ayon sa isang karaniwang template: ang mga mesa ng mga financier at mga opisyal ng operasyon ay dumating para sa pagsubok (ito ay dalawang magkaibang mga template).
Pagsubok
Para sa pagsubok, ginamit ang LoginVSI 4.1 software test suite. Ang LoginVSI complex, na binubuo ng isang control server at 12 machine para sa mga pagsubok na koneksyon, ay na-deploy sa isang hiwalay na pisikal na host.
Ang pagsubok ay isinagawa sa tatlong mga mode:
Benchmark mode - load cases 300 Knowledge workers at 300 Storage workers.
Standard mode - load case 300 Power workers.
Upang paganahin ang mga manggagawa ng Power na magtrabaho at madagdagan ang pagkakaiba-iba ng pagkarga, isang library ng karagdagang mga file ng Power Library ay idinagdag sa LoginVSI complex. Upang matiyak ang pag-uulit ng mga resulta, ang lahat ng mga setting ng test bench ay iniwan bilang Default.
Ginagaya ng mga pagsubok sa Knowledge at Power worker ang totoong workload ng mga user na nagtatrabaho sa mga virtual na workstation.
Ang pagsubok ng mga manggagawa sa Storage ay partikular na nilikha para sa pagsubok ng mga sistema ng pag-iimbak ng data; ito ay malayo sa mga totoong workload at kadalasang kinabibilangan ng gumagamit na nagtatrabaho sa isang malaking bilang ng mga file na may iba't ibang laki.
Sa panahon ng pagsubok, nagla-log in ang mga user sa mga workstation sa loob ng 48 minuto sa bilis na humigit-kumulang isang user bawat 10 segundo.
Natuklasan
Ang pangunahing resulta ng pagsubok sa LoginVSI ay ang sukatan ng VSImax, na pinagsama-sama mula sa oras ng pagpapatupad ng iba't ibang mga gawain na inilunsad ng gumagamit. Halimbawa: oras upang buksan ang isang file sa Notepad, oras upang i-compress ang isang file sa 7-Zip, atbp.
Available ang isang detalyadong paglalarawan ng pagkalkula ng mga sukatan sa opisyal na dokumentasyon para sa .
Sa madaling salita, inuulit ng LoginVSI ang isang tipikal na pattern ng pagkarga, ginagaya ang mga aksyon ng user sa isang office suite, nagbabasa ng PDF, at iba pa, at sumusukat ng iba't ibang latency. Mayroong isang kritikal na antas ng mga pagkaantala "lahat ay bumagal, imposibleng gumana"), bago ito itinuturing na ang maximum na bilang ng mga gumagamit ay hindi pa naabot. Kung ang oras ng pagtugon ay 1 ms na mas mabilis kaysa sa estadong ito na "mabagal ang lahat", kung gayon ang system ay itinuturing na gumagana nang normal, at mas maraming user ang maaaring maidagdag.
Narito ang mga pangunahing sukatan:
Mga sukatan
Mga ginawang aksyon
Detalyadong описание
Nag-load ng mga bahagi
N.S.L.D.
Oras ng pagbubukas ng text
file na tumitimbang ng 1 KB
Bumukas ang Notepad at
nagbubukas ng random na 1 KB na dokumento na kinopya mula sa pool
mapagkukunan
CPU at I/O
NFO
Oras ng pagbubukas ng dialogue
mga bintana sa notepad
Pagbubukas ng VSI-Notepad file [Ctrl+O]
CPU, RAM at I/O
ZHC*
Oras na para gumawa ng napaka-compress na Zip file
Lokal na compression
random na 5MB .pst file na kinopya mula sa
pool ng mapagkukunan
CPU at I/O
ZLC*
Oras na para gumawa ng mahinang naka-compress na Zip file
Lokal na compression
random na 5MB .pst file na kinopya mula sa
pool ng mapagkukunan
I / O
CPU
Pagkalkula ng malaki
random na hanay ng data
Paglikha ng Malaking Array
random na data na gagamitin sa input/output timer (I/O timer)
CPU
Kapag isinagawa ang pagsubok, ang pangunahing sukatan ng VSIbase ay unang kinakalkula, na nagpapakita ng bilis kung saan ang mga trabaho ay isinasagawa nang walang pag-load sa system. Batay dito, tinutukoy ang VSImax Threshold, na katumbas ng VSIbase + 1ms.
Ang mga konklusyon tungkol sa performance ng system ay ginawa batay sa dalawang sukatan: VSIbase, na tumutukoy sa bilis ng system, at VSImax threshold, na tumutukoy sa maximum na bilang ng mga user na kayang hawakan ng system nang walang makabuluhang pagkasira.
300 Knowledge workers benchmark
Ang mga manggagawa sa kaalaman ay mga user na regular na naglo-load ng memory, processor at IO na may iba't ibang maliliit na peak. Tinutularan ng software ang workload ng mga hinihingi na gumagamit ng opisina, na para bang patuloy silang tumutusok sa isang bagay (PDF, Java, office suite, pagtingin sa larawan, 7-Zip). Habang nagdaragdag ka ng mga user mula zero hanggang 300, unti-unting tumataas ang pagkaantala para sa bawat isa.
Data ng istatistika ng VSImax:
VSIbase = 986ms, hindi naabot ang VSI Threshold.
Mga istatistika ng pagkarga ng system ng imbakan mula sa pagsubaybay sa SimpliVity:
Sa ganitong uri ng pagkarga, ang sistema ay maaaring makatiis sa tumaas na pagkarga na halos walang pagkasira sa pagganap. Ang oras na kinakailangan upang makumpleto ang mga gawain ng user ay tumataas nang maayos, ang oras ng pagtugon ng system ay hindi nagbabago sa panahon ng pagsubok at hanggang sa 3 ms para sa pagsusulat at hanggang 1 ms para sa pagbabasa.
Konklusyon: Ang 300 mga user ng kaalaman ay nagtatrabaho sa kasalukuyang cluster nang walang anumang problema at hindi nakikialam sa isa't isa, na umaabot sa pCPU/vCPU na oversubscription na 1 hanggang 6. Ang mga pangkalahatang pagkaantala ay lumalaki nang pantay-pantay habang tumataas ang pag-load, ngunit hindi naabot ang itinakdang limitasyon.
300 Storage worker benchmark
Ito ang mga user na patuloy na nagsusulat at nagbabasa sa ratio na 30 hanggang 70, ayon sa pagkakabanggit. Ang pagsusulit na ito ay isinagawa nang higit pa para sa kapakanan ng eksperimento. Data ng istatistika ng VSImax:
VSIbase = 1673, naabot ang VSI Threshold sa 240 na user.
Mga istatistika ng pagkarga ng system ng imbakan mula sa pagsubaybay sa SimpliVity:
Ang ganitong uri ng pagkarga ay mahalagang pagsubok ng stress ng sistema ng imbakan. Kapag ito ay naisakatuparan, ang bawat user ay nagsusulat ng maraming random na file na may iba't ibang laki sa disk. Sa kasong ito, makikita na kapag ang isang tiyak na limitasyon ng pag-load ay lumampas para sa ilang mga gumagamit, ang oras na kinakailangan upang makumpleto ang mga gawain para sa pagsusulat ng mga file ay tataas. Kasabay nito, ang pag-load sa sistema ng imbakan, processor at memorya ng mga host ay hindi nagbabago nang malaki, kaya kasalukuyang imposibleng matukoy nang eksakto kung ano ang sanhi ng mga pagkaantala.
Ang mga konklusyon tungkol sa pagganap ng system gamit ang pagsubok na ito ay maaari lamang gawin kumpara sa mga resulta ng pagsubok sa iba pang mga system, dahil ang mga naturang load ay gawa ng tao at hindi makatotohanan. Gayunpaman, sa pangkalahatan ay naging maayos ang pagsubok. Naging maayos ang lahat hanggang sa 210 session, at nagsimula ang mga kakaibang tugon, na hindi nasubaybayan kahit saan maliban sa Login VSI.
300 mga manggagawa sa kuryente
Ito ang mga user na mahilig sa CPU, memory at mataas na IO. Ang mga "power user" na ito ay regular na nagpapatakbo ng mga kumplikadong gawain na may mahabang pagsabog, tulad ng pag-install ng bagong software at pag-unpack ng malalaking archive. Data ng istatistika ng VSImax:
VSIbase = 970, hindi naabot ang VSI Threshold.
Mga istatistika ng pagkarga ng system ng imbakan mula sa pagsubaybay sa SimpliVity:
Sa panahon ng pagsubok, naabot ang threshold ng pag-load ng processor sa isa sa mga node ng system, ngunit wala itong makabuluhang epekto sa pagpapatakbo nito:
Sa kasong ito, makakayanan ng system ang tumaas na pagkarga nang walang makabuluhang pagkasira ng pagganap. Ang oras na kinakailangan upang makumpleto ang mga gawain ng user ay tumataas nang maayos, ang oras ng pagtugon ng system ay hindi nagbabago sa panahon ng pagsubok at hanggang sa 3 ms para sa pagsusulat at hanggang 1 ms para sa pagbabasa.
Ang mga regular na pagsusuri ay hindi sapat para sa customer, at nagpatuloy kami: dinagdagan namin ang mga katangian ng VM (bilang ng mga vCPU upang suriin ang pagtaas ng labis na subscription at laki ng disk) at nagdagdag ng karagdagang pag-load.
Kapag nagsasagawa ng mga karagdagang pagsubok, ginamit ang sumusunod na pagsasaayos ng stand:
300 virtual desktop ang na-deploy sa isang 4vCPU, 4GB RAM, 80GB HDD na configuration.
Configuration ng isa sa mga test machine:
Ang mga makina ay naka-deploy sa Dedicated – Full Copy na opsyon:
300 Knowledge worker benchmark na may oversubscription 12
Data ng istatistika ng VSImax:
VSIbase = 921 ms, hindi naabot ang VSI Threshold.
Mga istatistika ng pagkarga ng system ng imbakan mula sa pagsubaybay sa SimpliVity:
Ang mga resultang nakuha ay katulad ng pagsubok sa nakaraang configuration ng VM.
300 mga manggagawa sa kuryente na may 12 labis na subscription
Data ng istatistika ng VSImax:
VSIbase = 933, hindi naabot ang VSI Threshold.
Mga istatistika ng pagkarga ng system ng imbakan mula sa pagsubaybay sa SimpliVity:
Sa panahon ng pagsubok na ito, naabot din ang threshold ng pag-load ng processor, ngunit hindi ito nagkaroon ng malaking epekto sa pagganap:
Ang mga resultang nakuha ay katulad ng pagsubok sa nakaraang configuration.
Ano ang mangyayari kung patakbuhin mo ang load sa loob ng 10 oras?
Ngayon tingnan natin kung magkakaroon ng "epekto ng akumulasyon" at magpatakbo ng mga pagsubok sa loob ng 10 oras na magkakasunod.
Ang mga pangmatagalang pagsubok at paglalarawan ng seksyon ay dapat na naglalayong sa katotohanan na gusto naming suriin kung anumang mga problema ay lilitaw sa truss sa ilalim ng matagal na pagkarga dito.
300 Knowledge worker benchmark + 10 oras
Bukod pa rito, sinubukan ang isang kaso ng pagkarga ng 300 manggagawang may kaalaman, na sinundan ng trabaho ng user sa loob ng 10 oras.
Data ng istatistika ng VSImax:
VSIbase = 919 ms, hindi naabot ang VSI Threshold.
VSImax Detalyadong data ng istatistika:
Ang graph ay nagpapakita na walang performance degradation na naobserbahan sa buong pagsubok.
Mga istatistika ng pagkarga ng system ng imbakan mula sa pagsubaybay sa SimpliVity:
Ang pagganap ng storage system ay nananatiling pareho sa buong pagsubok.
Karagdagang pagsubok kasama ang pagdaragdag ng synthetic load
Hiniling ng customer na magdagdag ng wild load sa disk. Upang gawin ito, isang gawain ang idinagdag sa storage system sa bawat virtual machine ng user para magpatakbo ng synthetic load sa disk kapag nag-log in ang user sa system. Ang pag-load ay ibinigay ng fio utility, na nagpapahintulot sa iyo na limitahan ang pag-load sa disk sa pamamagitan ng bilang ng IOPS. Sa bawat makina, isang gawain ang inilunsad upang maglunsad ng karagdagang load sa halagang 22 IOPS 70%/30% Random Read/Write.
300 Knowledge worker benchmark + 22 IOPS bawat user
Sa paunang pagsubok, ang fio ay natagpuan na magpataw ng makabuluhang CPU overhead sa mga virtual machine. Nagdulot ito ng mabilis na pag-overload ng CPU ng mga host at lubos na naapektuhan ang operasyon ng system sa kabuuan.
Host CPU load:
Kasabay nito, natural ding tumaas ang mga pagkaantala sa storage system:
Ang kakulangan ng kapangyarihan sa pag-compute ay naging kritikal sa paligid ng 240 mga gumagamit:
Dahil sa mga resultang nakuha, napagpasyahan na magsagawa ng pagsubok na hindi gaanong masinsinang CPU.
230 Office worker benchmark + 22 IOPS bawat user
Para bawasan ang load sa CPU, pinili ang uri ng pag-load ng mga manggagawa sa Office, at 22 IOPS ng synthetic load ang idinagdag din sa bawat session.
Nilimitahan ang pagsubok sa 230 session upang hindi lumampas sa maximum na load ng CPU.
Ang pagsubok ay pinatakbo sa mga gumagamit na tumatakbo sa loob ng 10 oras upang suriin ang katatagan ng system sa panahon ng pangmatagalang operasyon nang malapit sa pinakamataas na pagkarga.
Data ng istatistika ng VSImax:
VSIbase = 918 ms, hindi naabot ang VSI Threshold.
VSImax Detalyadong data ng istatistika:
Ang graph ay nagpapakita na walang performance degradation na naobserbahan sa buong pagsubok.
Mga istatistika ng pagkarga ng CPU:
Kapag nagsasagawa ng pagsubok na ito, halos maximum ang load sa CPU ng mga host.
Mga istatistika ng pagkarga ng system ng imbakan mula sa pagsubaybay sa SimpliVity:
Ang pagganap ng storage system ay nananatiling pareho sa buong pagsubok.
Ang load sa storage system sa panahon ng pagsubok ay humigit-kumulang 6 IOPS sa isang 500/60 ratio (40 IOPS read, 3 IOPS write), na humigit-kumulang 900 IOPS bawat workstation.
Ang oras ng pagtugon ay may average na 3 ms para sa pagsusulat at hanggang 1 ms para sa pagbabasa.
Kabuuan
Kapag ginagaya ang mga tunay na load sa imprastraktura ng HPE SimpliVity, nakuha ang mga resulta na nagpapatunay sa kakayahan ng system na suportahan ang mga virtual na desktop ng hindi bababa sa 300 Full Clone machine sa isang pares ng SimpliVity node. Kasabay nito, ang oras ng pagtugon ng sistema ng imbakan ay pinananatili sa pinakamainam na antas sa buong pagsubok.
Lubos kaming humanga sa diskarte ng mahabang pagsubok at paghahambing ng mga solusyon bago ang pagpapatupad. Maaari din naming subukan ang pagganap para sa iyong mga workload kung gusto mo. Kasama ang iba pang mga hyperconverged na solusyon. Ang nabanggit na customer ay tinatapos na ngayon ang mga pagsubok sa isa pang solusyon nang magkatulad. Ang kasalukuyang imprastraktura nito ay isang fleet lamang ng mga PC, isang domain at software sa bawat lugar ng trabaho. Ang paglipat sa VDI nang walang mga pagsubok ay, siyempre, medyo mahirap. Sa partikular, mahirap maunawaan ang mga tunay na kakayahan ng isang VDI farm nang hindi naglilipat ng mga tunay na user dito. At ang mga pagsubok na ito ay nagbibigay-daan sa iyo upang mabilis na suriin ang mga tunay na kakayahan ng isang partikular na system nang hindi nangangailangan na isangkot ang mga ordinaryong gumagamit. Dito nagmula ang pag-aaral na ito.
Ang pangalawang mahalagang diskarte ay ang customer ay agad na nakatuon sa tamang scaling. Dito maaari kang bumili ng karagdagang server at magdagdag ng sakahan, halimbawa, para sa 100 mga gumagamit, ang lahat ay mahuhulaan sa presyo ng gumagamit. Halimbawa, kapag kailangan nilang magdagdag ng 300 pang user, malalaman nila na kailangan nila ng dalawang server sa isang tinukoy nang configuration, sa halip na muling isaalang-alang ang pag-upgrade ng kanilang buong imprastraktura.
Ang mga posibilidad ng HPE SimpliVity federation ay kawili-wili. Ang negosyo ay hiwalay sa heograpiya, kaya makatuwirang mag-install ng sarili mong hiwalay na VDI hardware sa isang malayong opisina. Sa SimpliVity federation, ang bawat virtual machine ay ginagaya ayon sa isang iskedyul na may kakayahang mag-replicate sa pagitan ng mga geographically remote clusters nang napakabilis at walang load sa channel - ito ay isang built-in na backup ng isang napakahusay na antas. Kapag kinokopya ang mga VM sa pagitan ng mga site, ginagamit ang channel nang pinakamaliit hangga't maaari, at ginagawa nitong posible na bumuo ng napaka-kagiliw-giliw na mga arkitektura ng DR sa pagkakaroon ng iisang control center at isang grupo ng mga desentralisadong storage site.
Ang lahat ng ito ay pinagsama-samang ginagawang posible na suriin ang bahagi ng pananalapi sa mahusay na detalye, at ipapatong ang mga gastos ng VDI sa mga plano sa paglago ng kumpanya, at upang maunawaan kung gaano kabilis magbabayad ang solusyon at kung paano ito gagana. Dahil ang anumang VDI ay isang solusyon na sa huli ay nagse-save ng maraming mapagkukunan, ngunit sa parehong oras, malamang, nang walang cost-effective na pagkakataon na baguhin ito sa loob ng 5-7 taon ng paggamit.
Sa pangkalahatan, kung mayroon kang anumang mga tanong na hindi para sa komento, sumulat sa akin sa pamamagitan ng email [protektado ng email].
Pinagmulan: www.habr.com