Clientul a dorit VDI. S-a uitat foarte atent la combinația SimpliVity + VDI Citrix Virtual Desktop. Pentru toți operatorii, angajații din birouri în orașe și așa mai departe. Acolo sunt cinci mii de utilizatori doar în prima etapă de migrare, așa că au insistat pe testarea de stres. VDI poate începe să fie lent, poate să stea liniștit — și nu întotdeauna se întâmplă din cauza problemelor cu canalul. Am cumpărat un pachet de testare foarte puternic special pentru VDI și am supus infrastructura la încărcare până când a cedat la nivel de discuri și procesor.
Așadar, ne vor trebui o sticlă de plastic, software-ul LoginVSI pentru teste avansate VDI. Îl avem cu licențe pentru 300 de utilizatori. Apoi am luat echipament HPE SimpliVity 380 configurat, potrivit pentru sarcina de densitate maximă a utilizatorilor pe un singur server, am creat mașini virtuale cu o bună redistribuire, am instalat pe ele software de birou pe Win10 și am început testarea.
Configurarea Mitogen pentru Ansible este foarte simplă:
Sistem
Două noduri (servere) HPE SimpliVity 380 Gen10. Pe fiecare:
- 2 x Intel Xeon Platinum 8170 26c 2.1Ghz.
- Memorie RAM: 768GB, 12 x 64GB LRDIMMs DDR4 2666MHz.
- Controlerul principal de discuri: HPE Smart Array P816i-a SR Gen10.
- Discuri: 9 x 1.92 TB SATA 6Gb/s SSD (în configurație RAID6 7+2, adică este modelul Medium în termenii HPE SimpliVity).
- Plăci de rețea: 4 x 1Gb Eth (date utilizatori), 2 x 10Gb Eth (backend SimpliVity și vMotion).
- Plăci FPGA integrate speciale în fiecare nod pentru deduplicare/comprimare.
Nodurile sunt conectate între ele prin interconectare 10Gb Ethernet direct, fără un switch extern, care este folosit ca backend SimpliVity și pentru transferul de date a mașinilor virtuale prin NFS. Datele mașinilor virtuale din cluster sunt întotdeauna replicate între cele două noduri.
Nodurile sunt grupate într-un cluster VMware vSphere sub gestionarea vCenter.
Pentru efectuarea testării, a fost desfășurat un controler de domeniu și un broker de conexiuni Citrix. Controlerul de domeniu, brokerul și vCenter au fost mutate pe un cluster separat.
Ca infrastructură de testare, au fost desfășurate 300 de birouri virtuale în configurația Dedicated – Full Copy, adică fiecare birou virtual reprezintă o copie completă a imaginii originale a mașinii virtuale și păstrează toate modificările efectuate de utilizatori.
Fiecare mașină virtuală are 2vCPU și 4GB RAM:
Pe mașinile virtuale a fost instalat următorul software, necesar pentru efectuarea testării:
- Windows 10 (64-bit), versiunea 1809.
- Adobe Reader XI.
- Citrix Virtual Delivery Agent 1811.1.
- Doro PDF 1.82.
- Java 7 Update 13.
- Microsoft Office Professional Plus 2016.
Între noduri — replicare sincronizată. Fiecare bloc de date din cluster are două copii. Asta înseamnă că acum există un set complet de date pe fiecare dintre noduri. Când clusterul are trei sau mai multe noduri — copiile blocurilor sunt în două locații diferite. Atunci când se creează o nouă VM, se creează o copie suplimentară pe unul dintre nodurile clusterului. În cazul în care un nod se defectează, toate VM-urile care erau rulate pe acesta se repornesc automat pe alte noduri, unde au replici. Dacă un nod a ieșit din funcțiune pe o perioadă lungă, începe recuperarea treptată a redundanței, iar clusterul revine la rezervarea N+1.
Balansarea și stocarea datelor se desfășoară la nivelul stocării software a SimpliVity.
Mașinile virtuale rulează un cluster de virtualizare care le plasează în stocarea software. Birourile au fost preluate după un șablon standard: pentru test s-au utilizat birourile financiarilor și operatorilor (acestea sunt două șabloane diferite).
Testare
Pentru desfășurarea testării a fost folosit complexul de software LoginVSI 4.1. Complexul LoginVSI, compus dintr-un server de control și 12 mașini pentru conexiuni de testare, a fost desfășurat pe un host fizic separat.
Testarea s-a desfășurat în trei moduri:
Modul Benchmark — variante de sarcină 300 Knowledge workers și 300 Storage workers.
Modul standard — variantă de sarcină 300 Power workers.
Pentru a permite funcționarea Power workers și a crește diversitatea sarcinii, complexului LoginVSI i-a fost adăugată o bibliotecă de fișiere suplimentare, Power Library. Pentru a asigura repetabilitatea rezultatelor, toate setările bancului de testare au fost lăsate la setările implicite.
Testele Knowledge și Power workers imită sarcina reală a utilizatorilor care lucrează pe stații de lucru virtuale.
Testul Storage workers a fost creat special pentru testarea sistemelor de stocare a datelor, fiind departe de sarcinile reale și constând, în mare măsură, în activitățile utilizatorului cu un număr mare de fișiere de dimensiuni diferite.
În procesul de testare, utilizatorii se conectează la stațiile de lucru timp de 48 de minute, aproximativ un utilizator la fiecare 10 secunde.
Rezultate
Principala metrică obținută din testarea LoginVSI este VSImax, care se bazează pe timpul de execuție al diferitelor sarcini efectuate de utilizator. De exemplu: timpul de deschidere a unui fișier în Notepad, timpul de comprimare a unui fișier în 7-Zip etc.
O descriere detaliată a modului de calculare a metricilor este disponibilă în documentația oficială de la .
Cu alte cuvinte, LoginVSI replicatează un model standard de sarcină, simulând acțiunile utilizatorului în pachetul de birou, la citirea unui PDF și așa mai departe, măsurând diverse întârzieri. Există un nivel critic de întârziere «totul se blochează, este imposibil de lucrat»), până la atingerea căruia se consideră că numărul maxim de utilizatori nu este atins. Dacă timpul de răspuns este cu 1.000 ms mai rapid decât acest stadiu «totul se blochează», se consideră că sistemul funcționează normal și se pot adăuga mai mulți utilizatori.
Iată principalele metrici:
Metrică
Acțiuni efectuate
Detaliat descriere
Componentele încărcate
NSLD
Timpul de deschidere a unui fișier text
de 1.500 Kbyte
Se lansează Notepad și
deschide un document aleator de 1.500 Kbyte, copiat din pool
de resurse
CPU și I/O
NFO
Timpul de deschidere a ferestrei de dialog în Notepad
Deschiderea fișierului VSI-Notepad [Ctrl+O]
CPU, RAM și I/O
ZHC*
Timpul de creare a unui fișier Zip cu compresie puternică
Comprimarea unui fișier local aleator în format .pst de 5MB, copiat din
poolul de resurse
ZLC*
Timpul de creare a unui fișier Zip cu compresie slabă
CPU și I/O
I/O
Calcularea unui mare
poolul de resurse
ZLC*
Timpul de creare a unui fișier Zip cu compresie slabă
vector de date aleatoare
CPU
Crearea unui mare vector
de date aleatoare, care va fi utilizat în temporizatorul de input-output (I/O-timer)
În timpul testării, se calculează inițial metrica de bază VSIbase, care indică viteza de executare a sarcinilor fără încărcare pe sistem. Pe baza acesteia se determină pragul VSImax, care este egal cu VSIbase + 1.000 ms.
Concluziile despre performanța sistemului se bazează pe două metrici: VSIbase, care determină viteza de lucru a sistemului, și pragul VSImax, care determină numărul maxim de utilizatori pe care sistemul îl poate susține fără degradarea semnificativă a performanței.
CPU
Benchmark pentru 300 de cunoștințe de lucru
300 Knowledge workers benchmark
300 Knowledge workers benchmark
Lucrătorii de cunoștințe — sunt utilizatori care solicită în mod regulat memoria, procesorul și IO cu diferite vârfuri mici. Software-ul emulează sarcina utilizatorilor de birou exigenți, de parcă aceștia ar face mereu ceva (PDF, Java, pachet office, vizualizare fotografii, 7-Zip). Pe măsură ce numărul de utilizatori crește de la zero la 300, întârzierea fiecăruia crește treptat.
Datele statisticilor VSImax:
VSIbase = 986ms, pragul VSI nu a fost atins.
Statistica sarcinii pe sistemul de stocare din monitorizarea SimpliVity:
La acest tip de sarcină, sistemul suportă creșteri ale încărcării practic fără degradarea performanței. Timpul de execuție al sarcinilor utilizatorilor crește treptat, iar timpul de răspuns al sistemului nu se schimbă pe parcursul testului și este de până la 3 ms pentru scriere și până la 1 ms pentru citire.
Concluzie: 300 de utilizatori de cunoștințe funcționează fără probleme pe clusterul actual și nu se interferă unii cu alții, atingând o reînscriere pCPU/vCPU de 1 la 6. Întârzierile generale cresc uniform odată cu creșterea sarcinii, dar limita condiționată nu a fost atinsă.
Benchmark pentru 300 de lucrători de stocare
Aceștia sunt utilizatori care scriu și citesc constant în proporție de 30 la 70, respectiv. Acest test a fost efectuat mai mult ca un experiment. Datele statisticilor VSImax:
VSIbase = 1673, pragul VSI a fost atins la 240 de utilizatori.
Statistica sarcinii pe sistemul de stocare din monitorizarea SimpliVity:
Acest tip de sarcină este, de fapt, un test de stres pentru sistemul de stocare. La executarea acestuia, fiecare utilizator scrie pe disc o mulțime de fișiere aleatoare de dimensiuni diferite. În acest caz, se observa că, odată ce se depășește un anumit prag de sarcină, timpul de execuție al sarcinilor pentru unii utilizatori crește pentru scrierea fișierelor. Totuși, sarcina pe sistemul de stocare, procesor și memorie ale gazdelor nu se schimbă semnificativ, astfel că nu este posibil să se determine cu exactitate cauza întârzierilor în acest moment.
Concluziile privind performanța sistemului din acest test pot fi făcute doar prin compararea cu rezultatele testului pe alte sisteme, deoarece astfel de sarcini sunt sintetic, nerealiste. Cu toate acestea, în general testul a decurs destul de bine. Până la 210 sesiuni, totul a mers bine, iar apoi au apărut răspunsuri neclare, care de altfel nu erau urmărite nicăieri, cu excepția Login VSI.
300 de lucrători puternici
Aceștia sunt utilizatorii care apreciază procesoarele, memoria și IO-uri ridicate. Acești „utilizatori avansați” rulează în mod regulat sarcini complexe cu vârfuri lungi, cum ar fi instalarea de software nou și dezarhivarea arhivelor mari. Date statistice VSImax:
VSIbase = 970, pragul VSI nu a fost atins.
Statistica sarcinii pe sistemul de stocare din monitorizarea SimpliVity:
În timpul testării, a fost atins pragul de încărcare a procesoarelor pe unul dintre nodurile sistemului, dar acest lucru nu a avut un impact semnificativ asupra funcționării acesteia:
În acest caz, sistemul suportă creșterea încărcării fără o degradare semnificativă a performanței. Timpul de execuție al sarcinilor utilizatorilor crește treptat, timpul de răspuns al sistemului nu se schimbă pe parcursul testării și este de până la 3 ms la scriere și până la 1 ms la citire.
Testeului standard oferite clientului nu au fost suficiente, așa că am mers mai departe: am crescut caracteristicile VM-ului (numărul de vCPU, pentru a evalua creșterea supracontractării și dimensiunea discului) și am adăugat o sarcină suplimentară.
În cadrul testelor suplimentare, a fost utilizată următoarea configurație a standului:
Au fost desfășurate 300 de birouri virtuale în configurația 4vCPU, 4GB RAM, 80GB HDD.
Configurația uneia dintre mașinile de test:
Mașinile sunt desfășurate în varianta Dedicated – Full Copy:
Benchmark pentru 300 de Knowledge workers cu supracontractare 12
Datele statisticilor VSImax:
VSIbase = 921 ms, pragul VSI nu a fost atins.
Statistica sarcinii pe sistemul de stocare din monitorizarea SimpliVity:
Rezultatele obținute sunt similare cu testarea configurației anterioare a VM-ului.
300 Power workers cu supracontractare 12
Datele statisticilor VSImax:
VSIbase = 933, pragul VSI nu a fost atins.
Statistica sarcinii pe sistemul de stocare din monitorizarea SimpliVity:
În cadrul acestei testări a fost atins și pragul de încărcare a procesoarelor, dar acest lucru nu a avut un impact semnificativ asupra performanței:
Rezultatele obținute sunt similare cu testarea configurației anterioare.
Ce se va întâmpla dacă încărcăm timp de 10 ore?
Acum vom vedea dacă va exista un „efect de acumulare” și vom rula teste timp de 10 ore consecutive.
Teste lungi și descrierea secțiunii ar trebui să se concentreze pe ceea ce am dorit să verificăm dacă vor apărea probleme cu ferma sub o încărcare prelungită.
Benchmark pentru 300 de Knowledge workers + 10 ore
De asemenea, a fost realizat un test al unei variante de sarcină de 300 de knowledge workers cu muncă continuă timp de 10 ore.
Datele statisticilor VSImax:
VSIbase = 919 ms, pragul VSI nu a fost atins.
Date statistice detaliate VSImax:
Din grafic se observă că în timpul întregului test nu există degradări ale performanței.
Statistica sarcinii pe sistemul de stocare din monitorizarea SimpliVity:
Performanța sistemului de stocare rămâne constantă pe parcursul întregului test.
Testare suplimentară cu adăugarea unei sarcini sintetice.
Clientul a solicitat adăugarea unei sarcini intense pe disc. Pentru aceasta, pe sistemul de stocare, fiecărei mașini virtuale a utilizatorului i-a fost adăugat un job care să activeze o sarcină sintetică pe disc la logarea utilizatorului. Sarcina a fost generată de utilitarul fio, care permite limitarea sarcinii pe disc prin numărul de IOPS. Pe fiecare mașină a fost activat un job pentru a genera o sarcină suplimentară de 22 IOPS 70%/30% Citire/Scriere Aleatoare.
300 de lucrători cunoștințe benchmark + 22 IOPS per utilizator
În timpul testării inițiale, s-a constatat că fio generează o sarcină suplimentară semnificativă pe CPU-urile mașinilor virtuale. Acest lucru a dus la o suprasarcină rapidă a gazdelor pe CPU și a afectat semnificativ funcționarea generală a sistemului.
Sarcina pe CPU-urile gazdelor:
Întârzierea sistemului de stocare a crescut de asemenea într-o manieră previzibilă:
Lipsa de putere de calcul a devenit critică în jurul a 240 de utilizatori:
Ca urmare a rezultatelor obținute, s-a decis să se efectueze teste cu o sarcină mai puțin solicitantă pentru CPU.
230 de lucrători de birou benchmark + 22 IOPS per utilizator
Pentru a reduce sarcina pe CPU, a fost ales un tip de sarcină de lucrători de birou, adăugând în fiecare sesiune câte 22 IOPS de sarcină sintetică.
Testul a fost limitat la 230 de sesiuni pentru a nu depăși sarcina maximă pe CPU.
Testul a fost activat cu utilizatorii lucrând timp de 10 ore pentru a verifica stabilitatea sistemului la o sarcină de aproape maximă.
Datele statisticilor VSImax:
VSIbase = 918 ms, pragul VSI nu a fost atins.
Date statistice detaliate VSImax:
Din grafic se observă că în timpul întregului test nu există degradări ale performanței.
Datele statistice privind sarcina pe CPU:
În timpul acestui test, sarcina pe CPU-urile gazdelor a fost practic maximă.
Statistica sarcinii pe sistemul de stocare din monitorizarea SimpliVity:
Performanța sistemului de stocare rămâne constantă pe parcursul întregului test.
Sarcina pe sistemul de stocare în timpul testului a fost de aproximativ 6.500 IOPS, cu un raport de 60/40 (3.900 IOPS - citire, 2.600 IOPS - scriere), ceea ce înseamnă aproximativ 28 IOPS pentru fiecare stație de lucru.
Timpul de răspuns a fost în medie de 3 ms pentru scriere și până la 1 ms pentru citire.
Rezultatul
În simularea încărcărilor reale pe infrastructura HPE SimpliVity, au fost obținute rezultate care confirmă capacitatea sistemului de a gestiona cel puțin 300 de mașini Full Clone pe un set de noduri SimpliVity. În acest timp, timpul de răspuns al sistemului de stocare a fost menținut la un nivel optim pe parcursul întregului test.
Ne place foarte mult abordarea testelor lungi și compararea soluțiilor înainte de implementare. Putem testa performanța și pentru încărcările dumneavoastră, dacă doriți. Inclusiv pe alte soluții hiperconvergente. Clientul menționat în prezent finalizează teste pe o altă soluție în paralel. Infrastructura lor actuală constă pur și simplu dintr-un parc de calculatoare, un domeniu și software pe fiecare loc de muncă. A face tranziția la VDI fără teste este, desigur, destul de dificil. Este, în mod specific, complicat să înțelegem capacitățile reale ale fermei VDI fără a migra utilizatori reali pe aceasta. Aceste teste permit o evaluare rapidă a posibilităților reale ale unui sistem fără a implica utilizatori obișnuiți. De aici a apărut această cercetare.
O altă abordare importantă este că clientul a planificat din start o scalare corectă. Aici se pot achiziționa servere și adăuga o fermă, de exemplu, pentru 100 de utilizatori, totul este predictibil din punct de vedere al costului per utilizator. De exemplu, atunci când vor avea nevoie să adauge încă 300 de utilizatori, vor ști că au nevoie de două servere în configurația deja definită, fără a fi nevoiți să revizuiască opțiunile de modernizare a întregii lor infrastructuri.
Sunt interesante posibilitățile de federare ale HPE SimpliVity. Afacerea este geografic distribuită, așa că are sens să se instaleze un sistem VDI separat în biroul de la distanță. În federarea SimpliVity, fiecare mașină virtuală este replicată conform unui program, având posibilitatea de a face între clustere geografic distanțate foarte repede și fără a încărca canalul - acesta este un backup încorporat de foarte bun nivel. La replicarea VM-urilor între locații, canalul este utilizat într-o măsură minimă, ceea ce permite construirea unor arhitecturi DR foarte interesante în prezența unui singur centru de control și a multor locații de stocare descentralizate.
Toate acestea, în ansamblu, oferă posibilitatea de a evalua atât latura financiară în detaliu, cât și de a corela costurile VDI cu planurile de creștere ale companiei, și de a înțelege cât de repede se va amortiza soluția și cum va funcționa. Deoarece orice VDI reprezintă o soluție care, în cele din urmă, economisește o mulțime de resurse, dar este probabil că nu va oferi o oportunitate economică avantajoasă de a o schimba în decurs de 5–7 ani de utilizare.
În general, dacă mai aveți întrebări care nu sunt pentru comentarii, - scrieți-mi pe email la mk@croc.ru.
Sursa: habr.com
