🥇Kuidas töötab HPE SimpliVity 380 VDI jaoks: range koormustestimine

Kliendi soov oli VDI. Ta vaatas väga hoolsalt SimpliVity + VDI Citrix Virtual Desktop kombinatsiooni. Kõikide operaatorite, kontoritöötajate ning teiste jaoks. Esimeses migratsioonilaines on seal viis tuhat kasutajat, seetõttu nõudsid nad koormustestimist. VDI võib hakata aeglustuma, võib rahulikult seista — ja see ei pruugi alati juhtuda kanalite probleemide tõttu. Ostime VDI jaoks spetsiaalselt väga võimsa testimispaketi ja lõime infrastruktuuri, kuni see langes diskide ja protsessori tõkestuse alla.

Nii et meil on vaja plastpudelit, LoginVSI tarkvara keerukate VDI testide jaoks. Meil on see 300 kasutaja litsentsidega. Siis võtsime HPE SimpliVity 380 riistvara, mis on sobiv ülesande maksimaalse kasutajatiheduse saavutamiseks ühel serveril, lõime virtuaalmasinad hea ülekirjutamisega, paigaldasime neile Win10 kontoritarkvara ja hakkasime testima.

Lähme!

Süsteem

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

2 x Intel Xeon Platinum 8170 26-c 2.1GHz.
Mälu: 768GB, 12 x 64GB LRDIMMs DDR4 2666MHz.
Peamine ketta kontroller: HPE Smart Array P816i-a SR Gen10.
Kettad: 9 x 1.92 TB SATA 6Gb/s SSD (RAID6 7+2 konfiguratsioonis, st see on HPE SimpliVity mõisted Medium).
Võrgukaardid: 4 x 1Gb Eth (kasutajate andmed), 2 x 10Gb Eth (SimpliVity tagaplaan ja vMotion).
Igas sõlmes ekspert FPGA-kaardid dedupeerimise/compression jaoks.

Sõlmed on omavahel ühendatud 10Gb Ethernet interconnectiga otse ilma välist switch'ita, mida kasutatakse SimpliVity tagaplaanina ja virtuaalmasinate andmete edastamiseks NFS kaudu. Virtuaalmasinate andmed klastris järjepidevalt peegelduvad kahe sõlme vahel.

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

Testimise läbiviimiseks on paigaldatud domeeni kontroller ja Citrixi ühenduste vahendaja. Domeeni kontroller, vahendaja ja vCenter on eraldi klastris.

Testinfrastruktuurina on paigaldatud 300 virtuaalset töölaua konfiguratsioonis Dedicated – Full Copy, st iga töölaua esindab originaalset virtuaalmasina pilti ja salvestab kõik kasutajate tehtud muudatused.

Igal virtuaalsel masinal on 2vCPU 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 on sünkroonne replikatsioon. Igal andmepaketil klastris on kaks koopiat. See tähendab, et praegu on igas sõlmes täiskomplekt andmeid. Kui klaster sisaldab kolme või enamat sõlme, on koopiad kahes erinevas kohas. Uue VM loomisel luuakse lisakoopia ühes klastris sõlmes. Kui sõlm ebaõnnestub pikaks ajaks, siis algab järkjärguline üleliigsuse taastamine, ja klaster naaseb tagasi N+1 üleliigsuse tasemele.

Andmete tasakaalustamine ja salvestamine toimub SimpliVity tarkvaralise salvestuse tasandil.

Virtuaalsed masinad käitavad virtualiseerimisklastrit, mis disposeerib neid programmipõhises salvestuses. Töölauad võeti tüüplahendusena: testimiseks kasutati rahaga seotud töötajate ja operaatorite töölaudu (need on kaks erinevat lahendust).

Testimine

Testimise jaoks kasutati LoginVSI 4.1 testkompleksi. LoginVSI kompleks koosneb haldusteenuse serverist ja 12 testmasinast, mis on paigaldatud eraldi füüsilisele hostile.

Testimist viidi läbi kolmes režiimis:

Benchmark režiim — koormuse variandid 300 Knowledge workers ja 300 Storage workers.

Standardrežiim — koormuse variant 300 Power workers.

Power workers'i töötamise võimaldamiseks ja koormuse varieerimise suurendamiseks lisati LoginVSI kompleksi lisafailide Power Library teek. Tulemustes kordamise tagamiseks jäeti kõik testimise seade sätted Default.

Knowledge ja Power workers'i testid simuleerivad reaalseid kasutajate koormusi, kes töötavad virtuaalsetes tööjaamades.

Storage workers'i test on loodud spetsiaalselt andmesalvestusüsteemide testimiseks, see on kaugel reaalsest koormusest ja enamasti seisneb see kasutaja töös suure hulga erineva suurusega failidega.

Testimise käigus siseneb iga kasutaja tööjaamadele umbes 48 minuti jooksul, keskmiselt üks kasutaja iga 10 sekundi järel.

Tulemused

LoginVSI testimise peamine tulemus on VSImax mõõdik, mis koostatakse kasutaja käivitatavate erinevate ülesannete täitmise ajast. Näiteks: faili avamise aeg Notepadis, faili tihendamise aeg 7-Zipis jne.

Metrikate arvutamise üksikasjalik kirjeldus on saadaval ametlikus dokumentatsioonis. lingi kaudu.

Teisis sõnadega simuleerib LoginVSI tüüpilist koormusmustrit, simuleerides kasutaja tegevusi kontoritarkvaras, PDF-de lugemist jne, ning mõõdab erinevaid viivitusi. On olemas kriitiline viivituse tase 'kõik takerdub, töö tegemine võimatu', kuni selle saavutamiseni arvatakse, et maksimumkasutajaid ei ole saavutatud. Kui vastus 1000 ms enne 'kõik takerdub' seisundit, siis arvatakse, et süsteem töötab normaalselt ja võib veel kasutajaid juurde lisada.

Siin on peamised mõõdikud:

Mõõdik

Teostatavad tegevused

Üksikasjalik kirjeldus

Koormatud komponendid

NSLD

Aeg 1500 KB teksti faili avamiseks
Avatakse Notepad ja

avatakse juhuslik 1500 KB dokument, mis on kopeeritud ressursside kogumist
ressursid
CPU ja I/O

NFO

Aeg dialoogikasti avamiseks Notepadis

Faili avamine VSI-Notepad [Ctrl+O]
CPU, RAM ja I/O

ZHC*

Aeg tugeva kokkusurumisega Zip-faili loomiseks

Kohalikku

juhuslikku faili formaadis .pst suurusega 5 MB, mis on kopeeritud

ressurside kogumist
ZLC*
Aeg nõrga kokkusurumisega Zip-faili loomiseks

NFO

I/O

Suurte juhuslike andmete massiivi arvutamine

ressurside kogumist
ZLC*
Aeg nõrga kokkusurumisega Zip-faili loomiseks

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

CPU

Testimise käigus arvutatakse algne mõõdik VSIbase, mis näitab ülesannete täitmise kiirus ilma süsteemi koormuseta. Selle alusel määratakse VSImax Threshold, mis on VSIbase + 1000 ms.
Süsteemi jõudluse järeldused tehakse kahe mõõdiku alusel: VSIbase, mis määrab süsteemi töö kiiruse, ja VSImax threshold, mis määrab maksimaalse kasutajate arvu, mida süsteem talub ilma olulise halvenemiseta.

300 Knowledge workers benchmark
Knowledge workers on kasutajad, kes koormavad regulaarselt mälu, protsessorit ja I/O erinevate väikeste tippude kaudu. Tarkvara simuleerib nõudlikest kontoritöötajatest koormust, just nagu nad pidevalt midagi klikivad (PDF, Java, kontoritarkvara, fotode vaatamine, 7-Zip). Kasutajate arvu suurendamisel nullist 300-ni kasvab igaühe viivitus sujuvalt.

CPU

VSImax statistika:

VSIbase = 986 ms, VSI Threshold ei ole saavutatud.

Süsteemi salvestuskoormuse statistika SimpliVity jälgimisest:

Antud koormuse korral talub süsteem suurenenud koormust praktiliselt ilma jõudluse halvenemiseta. Kasutaja ülesannete täitmise aeg kasvab sujuvalt, süsteemi vastusaeg ei muutu testimise käigus ning ulatub kuni 3 ms kirjutamise ja kuni 1 ms lugemise puhul.

300 knowledge kasutajat töötavad praeguses klastris ilma probleemideta ja ei sega üksteist, saavutades pCPU/vCPU 1:6 üleliigse koormuse. Üldised viivitused kasvavad tasakaalustatult koormuse suurenedes, kuid ei ole saavutatud tinglikku piiri.

300 Storage workers benchmark

Need on kasutajad, kes kirjutavad ja loevad pidevalt suhetes 30:70. See test viidi läbi pigem eksperimentaalsetel eesmärkidel. VSImax statistika:

VSIbase = 1673, VSI Threshold saavutati 240 kasutaja juures.

Väljund: Selline koormus on sisuliselt salvestussüsteemi stressitest. Kogu selle käigus kirjutab iga kasutaja kettale palju juhuslikke faile erinevates suurustes. Sel juhul on näha, et koormuse teatud piiride ületamisel suureneb osalise kasutaja failide kirjutamise ülesannete täitmise aeg. Samas ei muutu salvestussüsteemi, protsessori ja hostide mälu koormus oluliselt, seetõttu ei ole praegu võimalik täpselt määrata, millise teguriga viivitused on seotud.

Süsteemi jõudluse järeldusi testimise käigus saab teha ainult võrreldes teiste süsteemide testitulemuste, kuna sellised koormused on süntetaalsed, ebausutavad. Siiski, üldiselt läks test hästi. Kuni 210 sessioonini läks kõik hästi, seejärel algasid kõige kummalisemad vastused, mida ei jälgitud kusagil mujal peale Login VSI.

300 Power workers

Need on kasutajad, kes armastavad protsessoreid, mälu ja kõrget I/O-d. Need 'edukad kasutajad' käivitavad regulaarselt keerulisi ülesandeid pikaajaliste tippudega, näiteks uue tarkvara installimist ja suurte arhiivide dekompresseerimist. VSImax statistika:

Need on kasutajad, kes kirjutavad ja loevad pidevalt suhetes 30:70. See test viidi läbi pigem eksperimentaalsetel eesmärkidel. VSImax statistika:

VSIbase = 970, VSI Threshold ei ole saavutatud.

Testimise käigus saavutati proportsioonide koormus ühe süsteemi sõlme protsessoritel, kuid see ei avaldanud olulist mõju süsteemi tööle:

Sel juhul talub süsteem suurenevat koormust samuti ilma olulise jõudluse halvenemiseta. Kasutaja ülesannete täitmise aeg kasvab sujuvalt, süsteemi vastusaeg ei muutu testimise käigus ning ulatub kuni 3 ms kirjutamise ja kuni 1 ms lugemise puhul.

Need kasutajad, kes hindavad protsessorit, mälu ja kõrge IO. Need „edukamad kasutajad“ käivitavad regulaarselt keerulisi ülesandeid, sealhulgas uut tarkvara installimist ja suurte arhiivide lahtipakkimist. VSImax statistika näitab:

VSIbase = 970, VSI lävi ei ole saavutatud.

Need on kasutajad, kes kirjutavad ja loevad pidevalt suhetes 30:70. See test viidi läbi pigem eksperimentaalsetel eesmärkidel. VSImax statistika:

Testimise käigus saavutati protsessorite koormuse lävi ühel süsteemi sõlmel, kuid see ei mõjutanud oluliselt süsteemi toimimist:

Selles olukorras suudab süsteem taluda koormuse tõusu ilma olulise tootlikkuse languseta. Kasutajate ülesannete täitmise aeg kasvab järk-järgult, süsteemi reageerimisaeg ei muutu testimise käigus ja jääb kuni 3 ms kirjutamise ja kuni 1 ms lugemise puhul.

Tavalikest testidest jõudis klient järeldusele, et neid on liiga vähe, ning me läksime edasi: tõstsime VM-ide omadusi (vCPU arv, et hinnata ülekoormuse tõusu ja ketta suurust) ja lisasime täiendava koormuse.

Täiendavate testide läbiviimiseks kasutati järgmist testimisringi konfiguratsiooni:
Käivitati 300 virtuaalset töökeskkonda konfiguratsioonis 4vCPU, 4GB RAM, 80GB HDD.

Ühe testmasina konfiguratsioon:

Masinad on paigaldatud Dedicated – Full Copy variandina:

300 Knowledge workers benchmark koos ülekoormusega 12

Need on kasutajad, kes kirjutavad ja loevad pidevalt suhetes 30:70. See test viidi läbi pigem eksperimentaalsetel eesmärkidel. VSImax statistika:

Saadud tulemused on sarnased eelmise VM konfiguratsiooni testimisega.

300 Power workers koos ülekoormusega 12

Need on kasutajad, kes kirjutavad ja loevad pidevalt suhetes 30:70. See test viidi läbi pigem eksperimentaalsetel eesmärkidel. VSImax statistika:

Selle testimise käigus saavutati ka CPU koormuse lävi, kuid see ei mõjutanud oluliselt jõudlust:

Saadud tulemused on sarnased eelmise konfiguratsiooni testimisega.

Mis juhtub, kui koormust hoida 10 tundi?

Nüüd vaatame, kas tekib „akumuleerumise efekt“, ja teeme teste järjest 10 tundi.

Pikad testid ja osakondade kirjeldus peaksid olema suunatud sellele, et kontrollida, kas tal on pikaajalise koormuse korral mingeid probleeme.

300 Knowledge workers benchmark + 10 tundi

Lisaks viidi läbi 300 knowledge workers koormustesti ning kasutajate töö jätkamine 10 tunni jooksul.

VSImax Detailed statistika:

Graafikust on näha, et testi jooksul ei esinenud jõudluse halvenemist.

Need on kasutajad, kes kirjutavad ja loevad pidevalt suhetes 30:70. See test viidi läbi pigem eksperimentaalsetel eesmärkidel. VSImax statistika:

Süsteemi salvestusjõudlus püsis kogu testi vältel samal tasemel.

Täiendav testimine koos sünteetilise koormuse lisamisega

Klient palus lisada ketta korralduses suurt koormust. Selleks lisati igaühe kasutaja virtuaalmasina salvestussüsteemi ülesanne sünteetilise ketta koormuse käivitamiseks, kui kasutaja süsteemi sisenes. Koormus tagati utiliidi fio abil, mis võimaldab piirata kettakoormust IOPSide arvu järgi. Igas masinas käivitus ülesanne täiendava koormuse nendega 22 IOPS 70%/30% Random Read/Write.

300 Knowledge workers benchmark + 22 IOPS kasutaja kohta

Esialgsete testide käigus leiti, et fio tekitab virtuaalmasinate protsessoritele olulise täiendava koormuse. See viis hostide kiirele CPU ülekoormusele ja mõjutas süsteemi tööd tervikuna.

Hostide CPU koormus:

Selle tulemusel suurenes ka salvestussüsteemi viivitused:

Arvutusvõimsuse puudumine muutus kriitiliseks umbes 240 kasutaja juures:

Saadud tulemuste põhjal otsustati teostada vähem CPU-d koormavaid katseid.

230 Office workers benchmark + 22 IOPS kasutaja kohta

CPU koormuse vähendamiseks valiti Office workers tüüpi koormus, iga seansi jaoks lisati ka 22 IOPS sünteetilist koormust.

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

Test käivitati, et jälgida kasutajate töö jätkumist 10 tunni jooksul süsteemi stabiilsuse kontrollimiseks, kui koormus on maksimumile lähedane.

VSImax Detailed statistika:

Graafikust on näha, et testi jooksul ei esinenud jõudluse halvenemist.

CPU koormuse statistika:

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

Süsteemi salvestusse koormus testi jooksul ulatus umbes 6 500 IOPS-ni 60/40 suhega (3900 IOPS - lugemine, 2600 IOPS - kirjutamine), mis vastab ligikaudu 28 IOPS-ile ühe töökoha kohta.

Keskmine reageerimisajaväline andme kirjutamisel oli 3 ms ja lugemisel kuni 1 ms.

Kokkuvõte

HPE SimpliVity infrastruktuuri reaalse koormuse simuleerimisel saadi tulemused, mis kinnitavad, et süsteem suudab pakkuda vähemalt 300 Full Clone virtuaalset töölaua masinat, mis töötavad kahe SimpliVity sõlmega. Samuti säilis salvestusüsteemi reaktsiooniaeg kogu testimise vältel optimaalsel tasemel.

Meil on väga hea meel, et lähenemine pikaajaliste testide ja lahenduste võrdlemise seadmisel enne rakendamist. Saame testida jõudlust ka teie koormuste jaoks, kui soovite. Sealhulgas teistel hüperkonvergeerivatel lahendustel. Mainitud klient lõpetab praegu katseid teise lahendusega paralleelselt. Tema praegune infrastruktuur on lihtsalt arvutipark, domeen ja tarkvara igas töökohas. Üleminek VDI-le ilma testideta on muidugi üsna keeruline. Eriti keeruline on mõista VDI farmi reaalseid võimalusi, kui sinna ei ole migreeritud reaalseid kasutajaid. Need testid võimaldavad kiiresti hinnata, millised on erinevate süsteemide tegelikud võimalused, ilma et oleks vaja kaasata tavalisi kasutajaid. Seetõttu tekkis selline uuring.

Teine oluline lähenemine on see, et klient on kohe planeerinud õige skaleeritavuse. Siin on võimalik osta server ja lisada farm, näiteks 100 kasutajale, kõik on kasutaja hinna osas etteennustatav. Näiteks, kui neil on vajadus lisada veel 300 kasutajat, teavad nad, et on vajalik kaks serverit juba määratud konfiguratsioonis, mitte uuesti analüüsida oma infrastruktuuri täiustamise võimalusi tervikuna.

HPE SimpliVity föderatsiooni võimalused on huvitavad. Äri on geograafiliselt jaotatud, seega on mõistlik paigaldada kau办公室 oma eraldi VDI riistvara. SimpliVity föderatsiooni korral replitseeritakse iga virtuaalmasin ajakava järgi, võimaldades teha geograafiliselt kaugete klastrite vahel väga kiiresti ja ilma võrgu koormuseta — see on kaasasolev varukoopia väga hea kvaliteediga. VM-de replitseerimisel erinevate asukohtade vahel kasutatakse kanalit minimaalsetes kogustes, kui võimalik, ja see võimaldab luua väga huvitavaid DR arhitektuure, omades ühtset halduskeskust ja hulgaliselt detsentraliseeritud salvestusplatse.

Föderatsioon

Kokkuvõttes annab see võimaluse hindamisse kaasata ka finantsaspektid väga üksikasjalikult, kattes VDI kulud ettevõtte kasvuplaanidega ning mõistes, kui kiiresti lahendus end ära tasub ja kuidas see töötama hakkab. Sest iga VDI on lahendus, mis säästab lõpuks massiliselt ressursse, kuid on tõenäoliselt ilma rahaliselt kasuliku võimaluseta seda 5–7 aastat pärast kasutuselevõttu vahetada.

Kui teil on küsimusi, mis ei ole kommentaaride jaoks, kirjutage mulle e-posti aadressile mk@croc.ru.

Allikas: habr.com