Klientas norėjo VDI. Aš tikrai pažvelgiau į SimpliVity + VDI Citrix Virtual Desktop derinį. Visiems operatoriams, miesto biuro darbuotojams ir pan. Vien per pirmąją migracijos bangą yra penki tūkstančiai vartotojų, todėl jie reikalavo atlikti apkrovos testavimą. VDI gali pradėti lėtėti, gali ramiai atsigulti – ir tai ne visada nutinka dėl kanalo problemų. Nusipirkome labai galingą testavimo paketą specialiai VDI ir krovėme infrastruktūrą tol, kol ji per daug apsunkėjo diskuose ir procesoriuje.
Taigi, mums reikės plastikinio butelio ir LoginVSI programinės įrangos sudėtingiems VDI testams. Turime jį su licencijomis 300 vartotojų. Tada paėmėme HPE SimpliVity 380 aparatinę įrangą pakete, tinkančiame maksimaliam vartotojų tankumui viename serveryje, supjaustėme virtualias mašinas su dideliu prenumeratos pertekliumi, įdiegėme jose Win10 biuro programinę įrangą ir pradėjome testavimą.
Eikime!
Sistema
Du HPE SimpliVity 380 Gen10 mazgai (serveriai). Kiekvienam:
- 2 x Intel Xeon Platinum 8170 26c 2.1GHz.
- RAM: 768 GB, 12 x 64 GB LRDIMM DDR4 2666 MHz.
- Pirminis disko valdiklis: HPE Smart Array P816i-a SR Gen10.
- Kietieji diskai: 9 x 1.92 TB SATA 6Gb/s SSD (RAID6 7+2 konfigūracijoje, t.y. tai yra vidutinis modelis HPE SimpliVity terminais).
- Tinklo plokštės: 4 x 1Gb Eth (vartotojo duomenys), 2 x 10Gb Eth (SimpliVity ir vMotion backend).
- Kiekviename mazge įmontuotos specialios FPGA kortelės, skirtos deduplikacijai / suspaudimui.
Mazgai yra sujungti vienas su kitu per 10Gb Ethernet jungtį tiesiogiai be išorinio jungiklio, kuris naudojamas kaip SimpliVity backend ir virtualios mašinos duomenims perduoti per NFS. Virtualios mašinos duomenys klasteryje visada atspindimi tarp dviejų mazgų.
Mazgai sujungiami į „Vmware vSphere“ klasterį, valdomą „vCenter“.
Bandymui buvo panaudotas domeno valdiklis ir „Citrix“ ryšio brokeris. Domeno valdiklis, brokeris ir vCenter yra atskirame klasteryje.
Kaip bandomoji infrastruktūra, 300 virtualių stalinių kompiuterių buvo įdiegta specialioje – visos kopijos konfigūracijoje, t. y. kiekvienas darbalaukis yra visa originalaus virtualiosios mašinos vaizdo kopija ir išsaugo visus vartotojų atliktus pakeitimus.
Kiekvienoje virtualioje mašinoje yra 2 vCPU ir 4 GB RAM:
Virtualiose mašinose buvo įdiegta ši testavimui reikalinga programinė įranga:
- „Windows 10“ (64 bitų), 1809 versija.
- Adobe Reader XI.
- Citrix virtualus pristatymo agentas 1811.1.
- Doro PDF 1.82.
- Java 7 naujinimas 13.
- Microsoft Office Professional Plus 2016.
Tarp mazgų – sinchroninė replikacija. Kiekvienas klasterio duomenų blokas turi dvi kopijas. Tai reiškia, kad dabar yra visas duomenų rinkinys apie kiekvieną mazgą. Kai yra trijų ar daugiau mazgų, blokų kopijos yra dviejose skirtingose vietose. Kuriant naują VM, viename iš klasterio mazgų sukuriama papildoma kopija. Kai vienas mazgas sugenda, visos jame anksčiau veikusios VM automatiškai paleidžiamos iš naujo kituose mazguose, kuriuose yra jų kopijos. Jei mazgas sugenda ilgą laiką, tada pradedamas laipsniškas pertekliaus atkūrimas, o klasteris grįžta į N+1 perteklumą.
Duomenų balansavimas ir saugojimas vyksta pačios SimpliVity programinės įrangos saugojimo lygyje.
Virtualiose mašinose veikia virtualizacijos klasteris, kuris taip pat talpina juos į programinės įrangos saugyklą. Patys stalai buvo paimti pagal standartinį šabloną: testui atėjo finansininkų ir operacijų pareigūnų stalai (tai du skirtingi šablonai).
Bandymai
Testavimui buvo naudojamas LoginVSI 4.1 programinės įrangos testų rinkinys. „LoginVSI“ kompleksas, susidedantis iš valdymo serverio ir 12 mašinų bandomiesiems ryšiams, buvo įdiegtas atskirame fiziniame pagrindiniame kompiuteryje.
Bandymai buvo atlikti trimis režimais:
Etaloninis režimas – apkrovos atvejai 300 žinių darbuotojų ir 300 sandėliavimo darbuotojų.
Standartinis režimas - apkrovos dėžė 300 Power darbuotojai.
Kad „Power“ darbuotojai galėtų dirbti ir padidinti apkrovų įvairovę, „LoginVSI“ komplekse buvo pridėta papildomų „Power Library“ failų biblioteka. Siekiant užtikrinti rezultatų pakartojamumą, visi bandymo stendo nustatymai buvo palikti kaip numatytieji.
Žinių ir energijos darbuotojų testai imituoja realų vartotojų, dirbančių virtualiose darbo vietose, darbo krūvį.
Saugyklų darbuotojų testas buvo sukurtas specialiai duomenų saugojimo sistemoms testuoti, jis toli gražu nėra tikras darbo krūvis ir dažniausiai apima vartotoją, dirbantį su daugybe įvairaus dydžio failų.
Bandymo metu vartotojai prisijungia prie darbo stočių 48 minutes maždaug po vieną vartotoją kas 10 sekundžių.
rezultatai
Pagrindinis LoginVSI testavimo rezultatas yra VSImax metrika, kuri yra sudaryta iš įvairių vartotojo paleistų užduočių vykdymo laiko. Pavyzdžiui: laikas atidaryti failą Notepad, laikas suspausti failą 7-Zip ir kt.
Išsamų metrikų skaičiavimo aprašymą rasite oficialiuose dokumentuose .
Kitaip tariant, „LoginVSI“ pakartoja tipišką įkėlimo modelį, imituodama vartotojo veiksmus biuro programoje, skaitydama PDF ir t. t., ir matuoja įvairius delsus. Yra kritinis vėlavimų lygis „viskas sulėtėja, dirbti neįmanoma“), prieš kurį laikoma, kad maksimalus vartotojų skaičius nepasiektas. Jei atsako laikas yra 1 ms greitesnis nei ši būsena „viskas lėtai“, laikoma, kad sistema veikia normaliai ir galima pridėti daugiau vartotojų.
Štai pagrindiniai rodikliai:
Metrika
Veiksmai, kurių buvo imtasi
Detalus описание
Pakrauti komponentai
N.S.L.D.
Teksto atidarymo laikas
failas, sveriantis 1 KB
Atsidaro užrašų knygelė ir
atidaromas atsitiktinis 1 KB dokumentas, nukopijuotas iš telkinio
išteklių
CPU ir I/O
NFO
Dialogo atidarymo laikas
langai užrašų knygelėje
VSI-Notepad failo atidarymas [Ctrl+O]
CPU, RAM ir I/O
ZHC*
Laikas sukurti labai suspaustą ZIP failą
Vietinis suspaudimas
atsitiktinis 5 MB .pst failas nukopijuotas iš
išteklių telkinys
CPU ir I/O
ZLC*
Laikas sukurti silpnai suspaustą ZIP failą
Vietinis suspaudimas
atsitiktinis 5 MB .pst failas nukopijuotas iš
išteklių telkinys
I / O
CPU
Skaičiuojant didelis
atsitiktinis duomenų masyvas
Didelio masyvo kūrimas
atsitiktiniai duomenys, kurie bus naudojami įvesties / išvesties laikmatyje (įvesties / išvesties laikmatis)
CPU
Atliekant testavimą, iš pradžių apskaičiuojama pagrindinė VSIbase metrika, kuri parodo greitį, kuriuo darbai atliekami neapkraunant sistemos. Pagal jį nustatomas VSImax Threshold, kuris lygus VSIbase + 1ms.
Išvados apie sistemos našumą daromos remiantis dviem metrikomis: VSIbase, kuri nustato sistemos greitį, ir VSImax slenkstį, kuris nustato maksimalų vartotojų skaičių, kurį sistema gali apdoroti be reikšmingo degradacijos.
300 žinių darbuotojų etalonas
Žinių darbuotojai yra vartotojai, kurie reguliariai įkelia atmintį, procesorių ir IO su įvairiomis mažomis smailėmis. Programinė įranga imituoja reiklių biuro vartotojų darbo krūvį, tarsi jie nuolat ką nors kištų (PDF, Java, biuro paketas, nuotraukų peržiūra, 7-Zip). Kai pridedate naudotojų nuo nulio iki 300, kiekvieno delsa palaipsniui didėja.
VSImax statistikos duomenys:
VSIbase = 986ms, VSI slenkstis nepasiektas.
Saugojimo sistemos apkrovos statistika iš „SimpliVity“ stebėjimo:
Esant tokio tipo apkrovai, sistema gali atlaikyti padidėjusį apkrovą praktiškai nepablogindama našumo. Vartotojo užduočių atlikimo laikas sklandžiai didėja, sistemos atsako laikas nesikeičia testavimo metu ir yra iki 3 ms rašant ir iki 1 ms skaitant.
Išvada: 300 žinių vartotojų dirba su esamu klasteriu be jokių problemų ir netrukdo vieni kitiems, pasiekdami pCPU/vCPU perteklinį prenumeratą nuo 1 iki 6. Bendras vėlavimų skaičius auga tolygiai didėjant apkrovai, tačiau numatyta riba nepasiekta.
300 sandėliavimo darbuotojų etalonas
Tai vartotojai, kurie nuolat rašo ir skaito santykiu nuo 30 iki 70. Šis bandymas buvo atliktas daugiau eksperimentavimo sumetimais. VSImax statistikos duomenys:
VSIbase = 1673, VSI slenkstis pasiektas 240 vartotojų.
Saugojimo sistemos apkrovos statistika iš „SimpliVity“ stebėjimo:
Šio tipo apkrova iš esmės yra saugojimo sistemos testavimas nepalankiausiomis sąlygomis. Kai jis vykdomas, kiekvienas vartotojas į diską įrašo daugybę atsitiktinių įvairaus dydžio failų. Šiuo atveju matyti, kad kai kuriems vartotojams viršijus tam tikrą apkrovos slenkstį, pailgėja failų rašymo užduočių atlikimo laikas. Tuo pačiu metu saugojimo sistemos, procesoriaus ir šeimininkų atminties apkrova iš esmės nesikeičia, todėl šiuo metu neįmanoma tiksliai nustatyti, kas sukelia vėlavimus.
Išvadas apie sistemos veikimą naudojant šį testą galima padaryti tik palyginus su kitų sistemų bandymų rezultatais, nes tokios apkrovos yra sintetinės ir nerealios. Tačiau apskritai testas praėjo gerai. Viskas klostėsi gerai iki 210 seansų, o tada prasidėjo keisti atsakymai, kurie niekur nebuvo sekami, išskyrus Login VSI.
300 energetikų
Tai vartotojai, kurie mėgsta procesorių, atmintį ir aukštą IO. Šie „pajėgūs vartotojai“ reguliariai vykdo sudėtingas užduotis su ilgomis serijomis, pavyzdžiui, įdiegia naują programinę įrangą ir išpakuoja didelius archyvus. VSImax statistikos duomenys:
VSIbase = 970, VSI slenkstis nepasiektas.
Saugojimo sistemos apkrovos statistika iš „SimpliVity“ stebėjimo:
Testavimo metu viename iš sistemos mazgų buvo pasiektas procesoriaus apkrovos slenkstis, tačiau tai neturėjo didelės įtakos jo veikimui:
Tokiu atveju sistema gali atlaikyti padidintą apkrovą be reikšmingo veikimo pablogėjimo. Vartotojo užduočių atlikimo laikas sklandžiai didėja, sistemos atsako laikas nesikeičia testavimo metu ir yra iki 3 ms rašant ir iki 1 ms skaitant.
Klientui nepakako reguliarių testų, žengėme toliau: padidinome VM charakteristikas (vCPU skaičių, kad būtų galima įvertinti perteklinio prenumeratos ir disko dydžio padidėjimą) ir pridėjome papildomą apkrovą.
Atliekant papildomus bandymus buvo naudojama tokia stovo konfigūracija:
300 virtualių stalinių kompiuterių buvo įdiegta 4 v CPU, 4 GB RAM, 80 GB HDD konfigūracijoje.
Vienos iš bandomųjų mašinų konfigūracija:
Mašinos įdiegtos naudojant parinktį Dedicated – Full Copy:
300 žinių darbuotojų etalonas su pertekliumi 12
VSImax statistikos duomenys:
VSIbase = 921 ms, VSI slenkstis nepasiektas.
Saugojimo sistemos apkrovos statistika iš „SimpliVity“ stebėjimo:
Gauti rezultatai yra panašūs į ankstesnės VM konfigūracijos testavimą.
300 elektros energijos darbuotojų su 12 perteklinių abonementų
VSImax statistikos duomenys:
VSIbase = 933, VSI slenkstis nepasiektas.
Saugojimo sistemos apkrovos statistika iš „SimpliVity“ stebėjimo:
Šio testavimo metu taip pat buvo pasiekta procesoriaus apkrovos riba, tačiau tai neturėjo didelės įtakos našumui:
Gauti rezultatai yra panašūs į ankstesnės konfigūracijos testavimą.
Kas atsitiks, jei dirbsite 10 valandų?
Dabar pažiūrėkime, ar bus „kaupimo efektas“, ir atlikite testus 10 valandų iš eilės.
Ilgalaikiai bandymai ir atkarpos aprašymas turėtų būti nukreipti į tai, kad norėjome patikrinti, ar nekils kokių nors problemų dėl santvaros ilgalaikės apkrovos.
300 žinių darbuotojų etalonas + 10 valandų
Be to, buvo išbandytas 300 žinių darbuotojų apkrovos atvejis, po kurio naudotojas dirbo 10 valandų.
VSImax statistikos duomenys:
VSIbase = 919 ms, VSI slenkstis nepasiektas.
VSImax Išsamios statistikos duomenys:
Diagrama rodo, kad viso bandymo metu nepastebėta jokio veikimo pablogėjimo.
Saugojimo sistemos apkrovos statistika iš „SimpliVity“ stebėjimo:
Saugojimo sistemos našumas išlieka toks pat viso bandymo metu.
Papildomi bandymai su sintetinės apkrovos priedu
Klientas paprašė pridėti laukinę apkrovą į diską. Norėdami tai padaryti, prie kiekvienos vartotojo virtualios mašinos saugojimo sistemos buvo pridėta užduotis paleisti sintetinę disko apkrovą, kai vartotojas prisijungia prie sistemos. Apkrovą suteikė „fio“ programa, leidžianti apriboti disko apkrovą IOPS skaičiumi. Kiekviename įrenginyje buvo paleista užduotis paleisti papildomą 22 IOPS 70%/30% atsitiktinio skaitymo/rašymo apkrovą.
300 žinių darbuotojų etalonas + 22 IOPS vienam vartotojui
Pradinio bandymo metu buvo nustatyta, kad fio virtualiose mašinose apkrauna daug procesoriaus. Tai lėmė greitą procesoriaus perkrovą pagrindiniuose kompiuteriuose ir labai paveikė visos sistemos veikimą.
Pagrindinio kompiuterio procesoriaus apkrova:
Tuo pačiu metu saugojimo sistemos vėlavimai taip pat natūraliai padidėjo:
Skaičiavimo galios trūkumas tapo kritinis maždaug 240 vartotojų:
Dėl gautų rezultatų buvo nuspręsta atlikti mažiau procesoriaus reikalaujančius bandymus.
230 biuro darbuotojų etalonas + 22 IOPS vienam vartotojui
Siekiant sumažinti procesoriaus apkrovą, buvo pasirinktas „Office“ darbuotojų apkrovos tipas, taip pat į kiekvieną seansą buvo pridėta 22 IOPS sintetinės apkrovos.
Bandymas buvo apribotas iki 230 seansų, kad nebūtų viršyta maksimali CPU apkrova.
Bandymas buvo atliktas naudotojams dirbant 10 valandų, siekiant patikrinti sistemos stabilumą ilgai veikiant esant beveik maksimaliai apkrovai.
VSImax statistikos duomenys:
VSIbase = 918 ms, VSI slenkstis nepasiektas.
VSImax Išsamios statistikos duomenys:
Diagrama rodo, kad viso bandymo metu nepastebėta jokio veikimo pablogėjimo.
CPU apkrovos statistika:
Atliekant šį testą, pagrindinio kompiuterio procesoriaus apkrova buvo beveik maksimali.
Saugojimo sistemos apkrovos statistika iš „SimpliVity“ stebėjimo:
Saugojimo sistemos našumas išlieka toks pat viso bandymo metu.
Bandymo metu saugojimo sistemos apkrova buvo maždaug 6 500 IOPS santykiu 60/40 (3 900 IOPS skaitymas, 2 600 IOPS rašymas), o tai yra maždaug 28 IOPS vienoje darbo vietoje.
Atsakymo laikas vidutiniškai buvo 3 ms rašant ir iki 1 ms skaitant.
Visas
Imituojant realias HPE SimpliVity infrastruktūros apkrovas, buvo gauti rezultatai, patvirtinantys sistemos gebėjimą palaikyti virtualius stalinius kompiuterius su mažiausiai 300 Full Clone mašinų poroje SimpliVity mazgų. Tuo pačiu metu saugojimo sistemos atsako laikas buvo palaikomas optimaliame lygyje viso bandymo metu.
Mums didelį įspūdį daro ilgas bandymas ir sprendimų palyginimas prieš įgyvendinant. Jei pageidaujate, galime patikrinti ir jūsų darbo krūvį. Įskaitant kitus hiperkonverguotus sprendimus. Minėtas klientas šiuo metu lygiagrečiai baigia kito sprendimo bandymus. Dabartinė jo infrastruktūra yra tiesiog kompiuterių parkas, domenas ir programinė įranga kiekvienoje darbo vietoje. Pereiti į VDI be testų, žinoma, gana sunku. Tiksliau sakant, sunku suprasti realias VDI ūkio galimybes, neperkėlus į jį tikrų vartotojų. O šie testai leidžia greitai įvertinti realias konkrečios sistemos galimybes, neįtraukiant paprastų vartotojų. Iš čia ir atsirado šis tyrimas.
Antras svarbus požiūris yra tai, kad klientas nedelsdamas įsipareigoja tinkamai pritaikyti mastelį. Čia galite nusipirkti papildomą serverį ir pridėti fermą, pavyzdžiui, 100 vartotojų, viskas yra nuspėjama už vartotojo kainą. Pavyzdžiui, kai jiems reikia pridėti dar 300 vartotojų, jie žinos, kad jiems reikia dviejų jau nustatytos konfigūracijos serverių, o ne svarstys, ar atnaujinti visą infrastruktūrą.
HPE SimpliVity federacijos galimybės įdomios. Verslas yra geografiškai atskirtas, todėl prasminga įdiegti savo atskirą VDI techninę įrangą tolimame biure. SimpliVity federacijoje kiekviena virtuali mašina yra replikuojama pagal grafiką su galimybe replikuotis tarp geografiškai nutolusių klasterių labai greitai ir neapkraunant kanalo – tai įmontuota labai gero lygio atsarginė kopija. Replikuojant VM tarp svetainių, kanalas išnaudojamas kuo mažiau, o tai leidžia sukurti labai įdomias DR architektūras esant vienam valdymo centrui ir krūvai decentralizuotų saugyklų.
Visa tai kartu leidžia itin detaliai įvertinti finansinę pusę, o VDI kaštus uždėti įmonės augimo planams ir suprasti, kaip greitai sprendimas atsipirks ir kaip veiks. Nes bet koks VDI yra sprendimas, kuris galiausiai sutaupo daug resursų, bet tuo pačiu, greičiausiai, be ekonomiškos galimybės jį pakeisti per 5-7 naudojimo metus.
Apskritai, jei turite klausimų, kurie nėra skirti komentuoti, rašykite man el [apsaugotas el. paštu].
Šaltinis: www.habr.com