Klient tahtis VDI-d. Vaatasin tõesti SimpliVity + VDI Citrix Virtual Desktopi kombinatsiooni. Kõigile operaatoritele, linnaameti töötajatele jne. Ainuüksi migratsiooni esimeses laines on viis tuhat kasutajat ja seetõttu nõudsid nad koormustestimist. VDI võib hakata aeglustuma, võib rahulikult pikali heita – ja see ei juhtu alati kanali probleemide tõttu. Ostsime spetsiaalselt VDI jaoks väga võimsa testimispaketi ja laadisime infrastruktuuri, kuni see oli ketastel ja protsessoril liiga raske.
Seega vajame keeruliste VDI-testide jaoks plastpudelit ja LoginVSI tarkvara. Meil on see litsentsidega 300 kasutajale. Seejärel võtsime HPE SimpliVity 380 riistvara paketis, mis sobis maksimaalse kasutajatihedusega serveri kohta, lõikasime üles hea ületellimusega virtuaalmasinad, installisime neile Win10 peal kontoritarkvara ja alustasime testimisega.
Mine!
Süsteem
Kaks HPE SimpliVity 380 Gen10 sõlme (serverit). Igaühel:
- 2 x Intel Xeon Platinum 8170 26c 2.1 GHz.
- RAM: 768 GB, 12 x 64 GB LRDIMM-id DDR4 2666 MHz.
- Peamine kettakontroller: HPE Smart Array P816i-a SR Gen10.
- Kõvakettad: 9 x 1.92 TB SATA 6Gb/s SSD (RAID6 7+2 konfiguratsioonis, st see on HPE SimpliVity mõistes Medium mudel).
- Võrgukaardid: 4 x 1Gb Eth (kasutajaandmed), 2 x 10Gb Eth (SimpliVity ja vMotion taustaprogramm).
- Igas sõlmes on spetsiaalsed sisseehitatud FPGA-kaardid dubleerimiseks/tihendamiseks.
Sõlmed on omavahel ühendatud 10Gb Etherneti vahendusel otse ilma välise lülitita, mida kasutatakse SimpliVity taustaprogrammina ja virtuaalmasina andmete edastamiseks NFS-i kaudu. Klastris olevad virtuaalmasina andmed peegeldatakse alati kahe sõlme vahel.
Sõlmed on ühendatud Vmware vSphere klastriks, mida haldab vCenter.
Testimiseks kasutati domeenikontrollerit ja Citrixi ühenduse vahendajat. Domeenikontroller, maakler ja vCenter paigutatakse eraldi klastrisse.
Testinfrastruktuurina kasutati 300 virtuaalset töölauda konfiguratsioonis Dedicated – Full Copy, st iga töölaud on virtuaalse masina algkujutise täielik koopia ja salvestab kõik kasutajate tehtud muudatused.
Igal virtuaalsel masinal on 2 vCPU ja 4 GB muutmälu:
Virtuaalsetesse masinatesse installiti järgmine testimiseks vajalik tarkvara:
- Windows 10 (64-bitine), versioon 1809.
- Adobe Reader XI.
- Citrixi virtuaalne kohaletoimetaja 1811.1.
- Doro PDF 1.82.
- Java 7 värskendus 13.
- Microsoft Office Professional Plus 2016.
Sõlmede vahel - sünkroonne replikatsioon. Igal klastri andmeplokil on kaks koopiat. See tähendab, et nüüd on iga sõlme kohta täielik andmete komplekt. Kolmest või enamast sõlmest koosnevas klastris on plokkide koopiad kahes erinevas kohas. Uue VM-i loomisel luuakse ühele klastri sõlmedest lisakoopia. Kui üks sõlm ebaõnnestub, taaskäivitatakse kõik sellel varem töötanud VM-id automaatselt teistes sõlmedes, kus neil on koopiad. Kui sõlm ebaõnnestub pikka aega, algab koondamise järkjärguline taastamine ja klaster naaseb N+1 liiasusele.
Andmete tasakaalustamine ja salvestamine toimub SimpliVity enda tarkvara salvestustasemel.
Virtuaalmasinad käitavad virtualiseerimisklastrit, mis paigutab need ka tarkvaramällu. Lauad ise olid võetud standardse malli järgi: testile tulid rahastajate ja operatiivametnike lauad (need on kaks erinevat malli).
Katsetamine
Testimiseks kasutati LoginVSI 4.1 tarkvara testkomplekti. LoginVSI kompleks, mis koosneb juhtserverist ja 12 masinast testühenduste jaoks, võeti kasutusele eraldi füüsilises hostis.
Testimine viidi läbi kolmes režiimis:
Võrdlusrežiim – laadige 300 teadmustöötajat ja 300 laotöötajat.
Standardrežiim - koormakast 300 Power worker.
Power töötajate töö võimaldamiseks ja koormuse mitmekesisuse suurendamiseks lisati LoginVSI kompleksi täiendavate Power Library failide teek. Tulemuste korratavuse tagamiseks jäeti kõik katsestendi seadistused vaikeseadeteks.
Teadmiste ja energiatöötajate testid simuleerivad virtuaalsetel tööjaamadel töötavate kasutajate tegelikku töökoormust.
Salvestustöötajate test loodi spetsiaalselt andmesalvestussüsteemide testimiseks, see on tegelikust töökoormusest kaugel ja hõlmab enamasti suure hulga erineva suurusega failidega töötamist.
Testimise ajal logivad kasutajad tööjaamadesse sisse 48 minutiks kiirusega umbes üks kasutaja iga 10 sekundi järel.
Järeldused
LoginVSI testimise peamiseks tulemuseks on VSImaxi mõõdik, mis on koostatud erinevate kasutaja poolt käivitatud ülesannete täitmise ajast. Näiteks: aeg faili avamiseks Notepadis, aeg faili tihendamiseks 7-Zip-vormingus jne.
Mõõdikute arvutamise üksikasjalik kirjeldus on saadaval ametlikus dokumentatsioonis .
Teisisõnu kordab LoginVSI tüüpilist laadimismustrit, simuleerides kasutaja toiminguid kontorikomplektis, lugedes PDF-i ja nii edasi, ning mõõdab erinevaid latentsusaega. On kriitiline viivituste tase "kõik aeglustub, pole võimalik töötada"), enne seda peetakse maksimaalset kasutajate arvu saavutamata. Kui reageerimisaeg on 1 ms kiirem kui see “kõik on aeglane” olek, siis loetakse süsteem normaalselt toimivaks ja kasutajaid saab juurde lisada.
Siin on peamised mõõdikud:
Mõõdikud
Võetud meetmed
Üksikasjalik описание
Laaditud komponendid
N.S.L.D.
Teksti avamise aeg
fail kaaluga 1 KB
Märkmik avaneb ja
avab juhusliku 1 KB suuruse dokumendi, mis kopeeritakse kogumist
ressursse
CPU ja I/O
NFO
Dialoogi avamise aeg
aknad märkmikus
VSI-Notepadi faili avamine [Ctrl+O]
CPU, RAM ja I/O
ZHC*
Aeg tihedalt tihendatud ZIP-faili loomiseks
Kohalik kokkusurumine
juhuslik 5MB .pst-fail kopeeriti
ressursside kogum
CPU ja I/O
ZLC*
Aeg luua nõrgalt tihendatud ZIP-fail
Kohalik kokkusurumine
juhuslik 5MB .pst-fail kopeeriti
ressursside kogum
I / O
Protsessor
Arvutades suur
juhuslik andmemassiivi
Suure massiivi loomine
juhuslikud andmed, mida kasutatakse sisend-/väljundtaimeris (I/O taimer)
Protsessor
Testimisel arvutatakse algselt välja VSIbase'i põhimõõdik, mis näitab kiirust, millega töid teostatakse ilma süsteemi koormamata. Selle põhjal määratakse VSImax Threshold, mis võrdub VSIbase + 1 ms.
Järeldused süsteemi jõudluse kohta tehakse kahe mõõdiku põhjal: VSIbase, mis määrab süsteemi kiiruse, ja VSImax lävi, mis määrab maksimaalse kasutajate arvu, millega süsteem suudab toime tulla ilma olulise halvenemiseta.
300 teadmustöötaja võrdlusalus
Teadmustöötajad on kasutajad, kes laadivad regulaarselt mälu, protsessorit ja IO-d erinevate väikeste tippudega. Tarkvara emuleerib nõudlike kontorikasutajate töökoormust, justkui torkaks nad pidevalt millegi kallale (PDF, Java, kontoripakett, fotode vaatamine, 7-Zip). Kui lisate kasutajaid nullist 300-le, pikeneb iga viivitus järk-järgult.
VSImaxi statistika andmed:
VSIbase = 986 ms, VSI lävi ei saavutatud.
Salvestussüsteemi laadimise statistika SimpliVity jälgimisest:
Seda tüüpi koormuse korral talub süsteem suurenenud koormust, ilma et see toimiks praktiliselt. Kasutaja ülesannete täitmiseks kuluv aeg pikeneb sujuvalt, süsteemi reageerimisaeg ei muutu testimise ajal ja on kirjutamisel kuni 3 ms ja lugemisel kuni 1 ms.
Järeldus: 300 teadmiste kasutajat töötavad praeguses klastris probleemideta ja ei sega üksteist, saavutades pCPU/vCPU ületellimuse 1 kuni 6. Üldised viivitused kasvavad koormuse kasvades ühtlaselt, kuid ettenähtud limiiti pole saavutatud.
300 laotöötaja võrdlusalus
Need on kasutajad, kes pidevalt kirjutavad ja loevad vahekorras vastavalt 30:70. See test viidi läbi rohkem katsetamise huvides. VSImaxi statistika andmed:
VSIbase = 1673, VSI lävi saavutas 240 kasutajat.
Salvestussüsteemi laadimise statistika SimpliVity jälgimisest:
Seda tüüpi koormus on sisuliselt salvestussüsteemi stressitest. Selle käivitamisel kirjutab iga kasutaja kettale palju erineva suurusega juhuslikke faile. Sel juhul on näha, et teatud laadimisläve ületamisel mõne kasutaja puhul pikeneb failide kirjutamise ülesannete täitmiseks kuluv aeg. Samas ei muutu oluliselt hostide salvestussüsteemi, protsessori ja mälu koormus, mistõttu on hetkel võimatu täpselt kindlaks teha, mis viivitusi põhjustab.
Järeldusi süsteemi jõudluse kohta selle testi abil saab teha ainult võrreldes teiste süsteemide katsetulemustega, kuna sellised koormused on sünteetilised ja ebareaalsed. Üldiselt läks test siiski hästi. Kuni 210 sessioonini läks kõik hästi ja siis algasid kummalised vastused, mida peale Login VSI kuskil ei jälgitud.
300 elektritöötajat
Need on kasutajad, kes armastavad protsessorit, mälu ja kõrget IO-d. Need "toimuvad kasutajad" täidavad regulaarselt keerulisi ja pikkade sarivõtetega ülesandeid, nagu uue tarkvara installimine ja suurte arhiivide lahtipakkimine. VSImaxi statistika andmed:
VSIbase = 970, VSI lävi ei saavutatud.
Salvestussüsteemi laadimise statistika SimpliVity jälgimisest:
Testimise ajal saavutati protsessori koormuslävi ühes süsteemisõlmes, kuid see ei mõjutanud oluliselt selle tööd:
Sel juhul talub süsteem suurenenud koormust ilma jõudluse olulise halvenemiseta. Kasutaja ülesannete täitmiseks kuluv aeg pikeneb sujuvalt, süsteemi reageerimisaeg ei muutu testimise ajal ja on kirjutamisel kuni 3 ms ja lugemisel kuni 1 ms.
Regulaarsest testimisest kliendile ei piisanud ja läksime kaugemale: suurendasime VM-i omadusi (vCPU-de arvu, et hinnata ületellimuse ja kettamahu suurenemist) ja lisasime lisakoormust.
Täiendavate testide läbiviimisel kasutati järgmist stendi konfiguratsiooni:
300 virtuaalset lauaarvutit kasutati 4 vCPU, 4 GB muutmälu ja 80 GB HDD konfiguratsioonis.
Ühe katsemasina konfiguratsioon:
Masinad on juurutatud valikus Pühendatud – täielik koopia:
300 teadmustöötaja võrdlusalus ületellimusega 12
VSImaxi statistika andmed:
VSIbase = 921 ms, VSI lävi ei saavutatud.
Salvestussüsteemi laadimise statistika SimpliVity jälgimisest:
Saadud tulemused on sarnased eelmise VM-i konfiguratsiooni testimisega.
300 elektritöötajat 12 ületellimusega
VSImaxi statistika andmed:
VSIbase = 933, VSI lävi ei saavutatud.
Salvestussüsteemi laadimise statistika SimpliVity jälgimisest:
Selle testimise käigus saavutati ka protsessori koormuslävi, kuid see ei mõjutanud jõudlust oluliselt:
Saadud tulemused on sarnased eelmise konfiguratsiooni testimisega.
Mis juhtub, kui töötate koormaga 10 tundi?
Nüüd vaatame, kas tekib "akumulatsiooniefekt" ja teeme teste 10 tundi järjest.
Pikaajalised katsetused ja lõigu kirjeldus peaksid olema suunatud sellele, et tahtsime kontrollida, kas sõrestikuga ei tekiks mingeid probleeme selle pikaajalisel koormusel.
300 teadmustöötaja võrdlusalus + 10 tundi
Lisaks testiti 300 teadmustöötaja koormusjuhtumit, millele järgnes 10-tunnine kasutajatöö.
VSImaxi statistika andmed:
VSIbase = 919 ms, VSI lävi ei saavutatud.
VSImax Üksikasjalikud statistikaandmed:
Graafik näitab, et kogu katse jooksul ei täheldatud jõudluse halvenemist.
Salvestussüsteemi laadimise statistika SimpliVity jälgimisest:
Salvestussüsteemi jõudlus jääb kogu testi vältel samaks.
Täiendav testimine sünteetilise koormuse lisamisega
Klient palus lisada kettale metsiku koormuse. Selleks lisati iga kasutaja virtuaalmasina salvestussüsteemile ülesanne käivitada kettale sünteetiline koormus, kui kasutaja süsteemi sisse logib. Koormuse andis fio utiliit, mis võimaldab piirata ketta koormust IOPS-i arvuga. Igas masinas käivitati ülesanne täiendava koormuse käivitamiseks summas 22 IOPS 70%/30% Random Read/Write.
300 teadmustöötaja võrdlusalus + 22 IOPS kasutaja kohta
Esialgse testimise käigus leiti, et fio põhjustab virtuaalsetele masinatele märkimisväärseid protsessorikulusid. See tõi kaasa hostide kiire CPU ülekoormuse ja mõjutas oluliselt süsteemi kui terviku tööd.
Hosti protsessori koormus:
Samal ajal suurenesid loomulikult ka salvestussüsteemide viivitused:
Arvutusvõimsuse puudumine muutus kriitiliseks umbes 240 kasutaja puhul:
Saadud tulemuste tõttu otsustati läbi viia vähem protsessorimahukad testid.
230 kontoritöötaja võrdlusalus + 22 IOPS kasutaja kohta
Protsessori koormuse vähendamiseks valiti Office'i töötajate koormuse tüüp ja igale seansile lisati ka 22 IOPS sünteetilist koormust.
Test piirdus 230 seansiga, et mitte ületada CPU maksimaalset koormust.
Test viidi läbi kasutajatega, kes töötasid 10 tundi, et kontrollida süsteemi stabiilsust pikaajalisel töötamisel maksimaalse koormuse lähedal.
VSImaxi statistika andmed:
VSIbase = 918 ms, VSI lävi ei saavutatud.
VSImax Üksikasjalikud statistikaandmed:
Graafik näitab, et kogu katse jooksul ei täheldatud jõudluse halvenemist.
Protsessori koormuse statistika:
Selle testi sooritamisel oli hostide protsessori koormus peaaegu maksimaalne.
Salvestussüsteemi laadimise statistika SimpliVity jälgimisest:
Salvestussüsteemi jõudlus jääb kogu testi vältel samaks.
Salvestussüsteemi koormus oli testi ajal ligikaudu 6 IOPS suhtega 500/60 (40 IOPS lugemist, 3 IOPS kirjutamist), mis on ligikaudu 900 IOPS tööjaama kohta.
Reaktsiooniaeg oli kirjutamisel keskmiselt 3 ms ja lugemisel kuni 1 ms.
Summaarne
HPE SimpliVity infrastruktuuri tegelike koormuste simuleerimisel saadi tulemused, mis kinnitasid süsteemi võimet toetada SimpliVity sõlme paaril vähemalt 300 Full Clone masinaga virtuaalseid töölaudu. Samal ajal püsis salvestussüsteemi reaktsiooniaeg kogu testimise vältel optimaalsel tasemel.
Meile avaldab suurt muljet pikkade testide lähenemine ja lahenduste võrdlemine enne rakendamist. Soovi korral võime testida ka teie töökoormust. Kaasa arvatud muud hüperkonvergeeritud lahendused. Nimetatud klient lõpetab nüüd paralleelselt teise lahenduse katseid. Selle praegune infrastruktuur on lihtsalt arvutipark, domeen ja tarkvara igal töökohal. VDI-le üleminek ilma testideta on muidugi üsna keeruline. Täpsemalt on VDI-farmi tegelikest võimalustest raske aru saada ilma tegelikke kasutajaid sinna migreerimata. Ja need testid võimaldavad teil kiiresti hinnata konkreetse süsteemi tegelikke võimeid, ilma et oleks vaja tavakasutajaid kaasata. Siit see uuring tuligi.
Teine oluline lähenemisviis on see, et klient kohustub viivitamatult korrektsele skaleerimisele. Siin saab juurde osta serveri ja lisada farmi näiteks 100 kasutajale, kasutajahinnaga on kõik etteaimatav. Näiteks kui neil on vaja lisada veel 300 kasutajat, teavad nad, et neil on vaja kahte serverit juba määratletud konfiguratsioonis, selle asemel et kaaluda kogu oma infrastruktuuri uuendamist.
HPE SimpliVity föderatsiooni võimalused on huvitavad. Ettevõte on geograafiliselt eraldatud, seega on mõistlik paigaldada oma eraldi VDI riistvara kaugemasse kontorisse. SimpliVity föderatsioonis paljundatakse iga virtuaalmasinat graafiku alusel koos võimalusega replitseerida geograafiliselt kaugete klastrite vahel väga kiiresti ja ilma kanalit koormamata – see on väga heal tasemel sisseehitatud varukoopia. VM-ide paljundamisel saitide vahel kasutatakse kanalit võimalikult minimaalselt ja see võimaldab ühe juhtimiskeskuse ja hulga detsentraliseeritud salvestuskohtade olemasolul ehitada väga huvitavaid DR-arhitektuure.
Kõik see kokku võimaldab hinnata väga detailselt rahalist poolt ning kanda VDI kulud ettevõtte kasvuplaanidesse ning mõista, kui kiiresti lahendus end ära tasub ja kuidas see toimima hakkab. Sest iga VDI on lahendus, mis kokkuvõttes säästab palju ressursse, kuid samas suure tõenäosusega ilma kulutõhusa võimaluseta seda 5-7 kasutusaasta jooksul vahetada.
Üldiselt, kui teil on küsimusi, mis pole kommenteerimiseks, kirjutage mulle e-posti teel [meiliga kaitstud].
Allikas: www.habr.com