Clientul dorea VDI. M-am uitat cu adevărat la combinația SimpliVity + VDI Citrix Virtual Desktop. Pentru toți operatorii, angajații birourilor municipale și așa mai departe. Numai în primul val de migrare există cinci mii de utilizatori și, prin urmare, au insistat asupra testării încărcării. VDI poate începe să încetinească, se poate întinde calm - și acest lucru nu se întâmplă întotdeauna din cauza problemelor cu canalul. Am cumpărat un pachet de testare foarte puternic special pentru VDI și am încărcat infrastructura până când a fost prea grea pentru discuri și procesor.
Deci, vom avea nevoie de o sticlă de plastic și software-ul LoginVSI pentru teste VDI sofisticate. Îl avem cu licențe pentru 300 de utilizatori. Apoi am luat hardware-ul HPE SimpliVity 380 într-un pachet potrivit pentru sarcina de densitate maximă a utilizatorilor pe server, am tăiat mașinile virtuale cu supraabonament bun, am instalat software de birou pe Win10 și am început testarea.
Să mergem!
Sistem
Două noduri HPE SimpliVity 380 Gen10 (servere). Pe fiecare:
- 2 x Intel Xeon Platinum 8170 26c 2.1 Ghz.
- RAM: 768 GB, 12 x 64 GB LRDIMM DDR4 2666 MHz.
- Controler de disc principal: HPE Smart Array P816i-a SR Gen10.
- Hard disk-uri: 9 x 1.92 TB SSD 6 Gb/s (în configurație RAID6 7+2, adică acesta este un model mediu în termeni HPE SimpliVity).
- Plăci de rețea: 4 x 1 Gb Eth (date utilizator), 2 x 10 Gb Eth (backend SimpliVity și vMotion).
- Carduri speciale FPGA încorporate în fiecare nod pentru deduplicare/comprimare.
Nodurile sunt conectate între ele printr-o interconexiune Ethernet de 10 Gb direct fără un comutator extern, care este folosit ca backend SimpliVity și pentru transferul datelor mașinii virtuale prin NFS. Datele mașinii virtuale dintr-un cluster sunt întotdeauna reflectate între două noduri.
Nodurile sunt combinate într-un cluster Vmware vSphere gestionat de vCenter.
Pentru testare, au fost implementate un controler de domeniu și un broker de conexiune Citrix. Controlerul de domeniu, brokerul și vCenter sunt plasate pe un cluster separat.
Ca infrastructură de testare, 300 de desktop-uri virtuale au fost implementate în configurația Dedicated – Full Copy, adică fiecare desktop este o copie completă a imaginii originale a mașinii virtuale și salvează toate modificările făcute de utilizatori.
Fiecare mașină virtuală are 2vCPU și 4GB RAM:
Următorul software necesar pentru testare a fost instalat pe mașinile virtuale:
- Windows 10 (64 de biți), versiunea 1809.
- Adobe Reader XI.
- Citrix Virtual Delivery Agent 1811.1.
- Doro PDF 1.82.
- Actualizarea Java 7 13.
- Microsoft Office Professional Plus 2016.
Între noduri - replicare sincronă. Fiecare bloc de date din cluster are două copii. Adică, acum există un set complet de date pe fiecare dintre noduri. Cu un grup de trei sau mai multe noduri, copiile blocurilor sunt în două locuri diferite. La crearea unei noi VM, o copie suplimentară este creată pe unul dintre nodurile clusterului. Când un nod eșuează, toate VM-urile care rulau anterior pe el sunt repornite automat pe alte noduri unde au replici. Dacă un nod eșuează pentru o lungă perioadă de timp, atunci începe restabilirea treptată a redundanței, iar clusterul revine la redundanța N+1.
Echilibrarea și stocarea datelor au loc la nivelul de stocare software al SimpliVity în sine.
Mașinile virtuale rulează un cluster de virtualizare, care le plasează și pe stocarea software. Birourile în sine au fost luate după un șablon standard: birourile finanțatorilor și ale ofițerilor de operațiuni au venit la test (acestea sunt două șabloane diferite).
Testarea
Pentru testare a fost folosită suita de testare software LoginVSI 4.1. Complexul LoginVSI, format dintr-un server de control și 12 mașini pentru conexiuni de testare, a fost implementat pe o gazdă fizică separată.
Testarea a fost efectuată în trei moduri:
Modul benchmark - cazuri de încărcare 300 de lucrători în cunoștințe și 300 de lucrători în stocare.
Mod standard - caz de sarcină 300 Muncitori de putere.
Pentru a permite lucrătorilor Power să lucreze și să crească diversitatea încărcării, la complexul LoginVSI a fost adăugată o bibliotecă de fișiere Power Library suplimentare. Pentru a asigura repetabilitatea rezultatelor, toate setările bancului de testare au fost lăsate ca implicite.
Testele pentru lucrătorii Knowledge and Power simulează volumul real de lucru al utilizatorilor care lucrează pe stațiile de lucru virtuale.
Testul pentru lucrători în stocare a fost creat special pentru testarea sistemelor de stocare a datelor; este departe de încărcături reale de lucru și implică în mare parte utilizatorul care lucrează cu un număr mare de fișiere de diferite dimensiuni.
În timpul testării, utilizatorii se conectează la stațiile de lucru timp de 48 de minute la o rată de aproximativ un utilizator la fiecare 10 secunde.
Constatări
Principalul rezultat al testării LoginVSI este metrica VSImax, care este compilată din timpul de execuție a diferitelor sarcini lansate de utilizator. De exemplu: timpul pentru a deschide un fișier în Notepad, timpul pentru a comprima un fișier în 7-Zip etc.
O descriere detaliată a calculului valorilor este disponibilă în documentația oficială pentru .
Cu alte cuvinte, LoginVSI repetă un model de încărcare tipic, simulând acțiunile utilizatorului într-o suită de birou, citirea unui PDF și așa mai departe și măsoară diverse latențe. Există un nivel critic de întârzieri „totul încetinește, este imposibil să funcționeze”), înainte de care se consideră că numărul maxim de utilizatori nu a fost atins. Dacă timpul de răspuns este cu 1 ms mai rapid decât această stare „totul este lent”, atunci se consideră că sistemul funcționează normal și pot fi adăugați mai mulți utilizatori.
Iată principalele valori:
Valori
Actiuni luate
Detaliat описание
Componente încărcate
N.S.L.D.
Ora de deschidere a textului
fișier cântărind 1 KB
Se deschide Notepad și
deschide un document aleatoriu de 1 KB care este copiat din grup
resurse
CPU și I/O
NFO
Ora de deschidere a dialogului
ferestre în notepad
Deschiderea unui fișier VSI-Notepad [Ctrl+O]
CPU, RAM și I/O
ZHC*
Este timpul să creați un fișier Zip foarte comprimat
Compresie locală
fișier aleatoriu .pst de 5MB copiat din
pool de resurse
CPU și I/O
ZLC*
Este timpul să creați un fișier Zip slab comprimat
Compresie locală
fișier aleatoriu .pst de 5MB copiat din
pool de resurse
I / O
Procesor
Calcul mare
matrice de date aleatoare
Crearea unui tablou mare
date aleatorii care vor fi utilizate în temporizatorul de intrare/ieșire (temporizator I/O)
Procesor
Când se efectuează testarea, se calculează inițial metrica de bază VSIbase, care arată viteza cu care lucrările sunt executate fără încărcare pe sistem. Pe baza acestuia, se determină pragul VSImax, care este egal cu VSIbase + 1 ms.
Concluziile despre performanța sistemului se fac pe baza a două metrici: VSIbase, care determină viteza sistemului, și VSImax threshold, care determină numărul maxim de utilizatori pe care sistemul îi poate gestiona fără o degradare semnificativă.
300 de lucrători cu cunoștințe de referință
Lucrătorii de cunoștințe sunt utilizatori care încarcă în mod regulat memoria, procesorul și IO cu diferite vârfuri mici. Software-ul emulează volumul de muncă al utilizatorilor pretențioși de birou, de parcă ar fi căutat în mod constant ceva (PDF, Java, suită de birou, vizualizare fotografii, 7-Zip). Pe măsură ce adăugați utilizatori de la zero la 300, întârzierea pentru fiecare crește treptat.
Date statistice VSImax:
VSIbase = 986 ms, pragul VSI nu a fost atins.
Statistici de încărcare a sistemului de stocare din monitorizarea SimpliVity:
Cu acest tip de sarcină, sistemul poate rezista la o sarcină crescută, practic fără nicio degradare a performanței. Timpul necesar pentru finalizarea sarcinilor utilizatorului crește fără probleme, timpul de răspuns al sistemului nu se modifică în timpul testării ș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 lucrează pe clusterul actual fără probleme și nu interferează unul cu celălalt, ajungând la supraabonamentul pCPU/vCPU de la 1 la 6. Întârzierile generale cresc uniform pe măsură ce sarcina crește, dar limita stipulată nu a fost atinsă.
300 de angajați în depozit
Aceștia sunt utilizatori care scriu și citesc constant într-un raport de 30 la 70, respectiv. Acest test a fost efectuat mai mult de dragul experimentului. Date statistice VSImax:
VSIbase = 1673, pragul VSI atins la 240 de utilizatori.
Statistici de încărcare a sistemului de stocare din monitorizarea SimpliVity:
Acest tip de sarcină este în esență un test de stres al sistemului de stocare. Când este executat, fiecare utilizator scrie multe fișiere aleatorii de diferite dimensiuni pe disc. În acest caz, se poate observa că atunci când un anumit prag de încărcare este depășit pentru unii utilizatori, timpul necesar pentru finalizarea sarcinilor de scriere a fișierelor crește. În același timp, încărcarea sistemului de stocare, procesorului și memoriei gazdelor nu se modifică semnificativ, astfel încât în prezent este imposibil să se determine exact ce cauzează întârzierile.
Concluziile despre performanța sistemului folosind acest test pot fi făcute numai în comparație cu rezultatele testelor pe alte sisteme, deoarece astfel de sarcini sunt sintetice și nerealiste. Totuși, per total, testul a decurs bine. Totul a mers bine până la 210 sesiuni, apoi au început răspunsuri ciudate, care nu au fost urmărite nicăieri în afară de Login VSI.
300 de muncitori la putere
Aceștia sunt utilizatori care iubesc CPU, memoria și IO ridicat. Acești „utilizatori cu putere” execută în mod regulat sarcini complexe cu explozii lungi, cum ar fi instalarea de software nou și despachetarea arhivelor mari. Date statistice VSImax:
VSIbase = 970, pragul VSI nu a fost atins.
Statistici de încărcare a sistemului de stocare din monitorizarea SimpliVity:
În timpul testării, pragul de încărcare a procesorului a fost atins pe unul dintre nodurile sistemului, dar acest lucru nu a avut un impact semnificativ asupra funcționării acestuia:
În acest caz, sistemul poate rezista la o sarcină crescută fără o degradare semnificativă a performanței. Timpul necesar pentru finalizarea sarcinilor utilizatorului crește fără probleme, timpul de răspuns al sistemului nu se modifică în timpul testării și este de până la 3 ms pentru scriere și până la 1 ms pentru citire.
Testele regulate nu au fost suficiente pentru client și am mers mai departe: am crescut caracteristicile VM (numărul de vCPU pentru a evalua creșterea supraabonamentului și dimensiunea discului) și am adăugat încărcare suplimentară.
La efectuarea unor teste suplimentare, a fost utilizată următoarea configurație de stand:
300 de desktop-uri virtuale au fost implementate într-o configurație de 4vCPU, 4GB RAM, 80GB HDD.
Configurația uneia dintre mașinile de testare:
Mașinile sunt implementate în opțiunea Dedicat – Copiere completă:
300 de lucrători din cunoștințe de referință cu supraabonament 12
Date statistice VSImax:
VSIbase = 921 ms, pragul VSI nu a fost atins.
Statistici de încărcare a sistemului de stocare din monitorizarea SimpliVity:
Rezultatele obținute sunt similare cu testarea configurației anterioare VM.
300 de lucrători cu putere cu 12 supraabonamente
Date statistice VSImax:
VSIbase = 933, pragul VSI nu a fost atins.
Statistici de încărcare a sistemului de stocare din monitorizarea SimpliVity:
În timpul acestei teste, a fost atins și pragul de încărcare a procesorului, dar acest lucru nu a avut un impact semnificativ asupra performanței:
Rezultatele obținute sunt similare cu testarea configurației anterioare.
Ce se întâmplă dacă rulați încărcătura timp de 10 ore?
Acum să vedem dacă va exista un „efect de acumulare” și să rulăm teste timp de 10 ore la rând.
Testele pe termen lung și descrierea secțiunii ar trebui să vizeze faptul că am dorit să verificăm dacă ar apărea vreo problemă cu ferme sub sarcină prelungită asupra acesteia.
300 de lucrători cu cunoștințe de referință + 10 ore
În plus, a fost testat un caz de încărcare de 300 de lucrători în cunoștințe, urmat de lucrul utilizatorului timp de 10 ore.
Date statistice VSImax:
VSIbase = 919 ms, pragul VSI nu a fost atins.
VSImax Date statistice detaliate:
Graficul arată că nu s-a observat nicio degradare a performanței pe parcursul întregului test.
Statistici de încărcare a sistemului de stocare din monitorizarea SimpliVity:
Performanța sistemului de stocare rămâne aceeași pe tot parcursul testului.
Testare suplimentară cu adăugarea de încărcătură sintetică
Clientul a cerut să adauge o încărcare sălbatică pe disc. Pentru a face acest lucru, a fost adăugată o sarcină sistemului de stocare în fiecare dintre mașinile virtuale ale utilizatorului pentru a rula o încărcare sintetică pe disc atunci când utilizatorul se conectează la sistem. Încărcarea a fost furnizată de utilitarul fio, care vă permite să limitați încărcarea de pe disc cu numărul de IOPS. În fiecare mașină, a fost lansată o sarcină pentru a lansa o încărcare suplimentară în valoare de 22 IOPS 70%/30% Citire/Scriere aleatorie.
300 de angajați în cunoștințe + 22 IOPS per utilizator
La testarea inițială, s-a descoperit că fio impune o supraîncărcare semnificativă a CPU pe mașinile virtuale. Acest lucru a condus la supraîncărcarea rapidă a CPU a gazdelor și a afectat foarte mult funcționarea sistemului în ansamblu.
Încărcarea procesorului gazdă:
În același timp, întârzierile sistemului de stocare au crescut în mod natural:
Lipsa puterii de calcul a devenit critică în jurul a 240 de utilizatori:
Datorită rezultatelor obținute, s-a decis să se efectueze teste care să consume mai puțin CPU.
230 de angajați de birou + 22 IOPS per utilizator
Pentru a reduce sarcina CPU, a fost selectat tipul de încărcare pentru lucrătorii Office și 22 IOPS de încărcare sintetică au fost adăugate la fiecare sesiune.
Testul a fost limitat la 230 de sesiuni pentru a nu depăși sarcina maximă a CPU.
Testul a fost efectuat cu utilizatorii rulând timp de 10 ore pentru a verifica stabilitatea sistemului în timpul funcționării pe termen lung la sarcina maximă aproape.
Date statistice VSImax:
VSIbase = 918 ms, pragul VSI nu a fost atins.
VSImax Date statistice detaliate:
Graficul arată că nu s-a observat nicio degradare a performanței pe parcursul întregului test.
Statistici de încărcare CPU:
La efectuarea acestui test, sarcina CPU-ului gazdelor a fost aproape maximă.
Statistici de încărcare a sistemului de stocare din monitorizarea SimpliVity:
Performanța sistemului de stocare rămâne aceeași pe tot parcursul testului.
Sarcina sistemului de stocare în timpul testului a fost de aproximativ 6 IOPS într-un raport 500/60 (40 IOPS de citire, 3 IOPS de scriere), ceea ce este de aproximativ 900 IOPS pe 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.
Total
La simularea sarcinilor reale pe infrastructura HPE SimpliVity, s-au obținut rezultate care confirmă capacitatea sistemului de a suporta desktop-uri virtuale de cel puțin 300 de mașini Full Clone pe o pereche de noduri SimpliVity. În același timp, timpul de răspuns al sistemului de stocare a fost menținut la un nivel optim pe toată durata testării.
Suntem foarte impresionați de abordarea testelor lungi și de compararea soluțiilor înainte de implementare. Putem testa performanța și pentru sarcinile dvs. de lucru, dacă doriți. Inclusiv alte soluții hiperconvergente. Clientul menționat finalizează acum testele pe o altă soluție în paralel. Infrastructura sa actuală este pur și simplu o flotă de PC-uri, un domeniu și software la fiecare loc de muncă. Trecerea la VDI fără teste este, desigur, destul de dificilă. Mai exact, este dificil de înțeles capabilitățile reale ale unei ferme VDI fără a migra utilizatori reali la aceasta. Și aceste teste vă permit să evaluați rapid capacitățile reale ale unui anumit sistem, fără a fi nevoie să implicați utilizatorii obișnuiți. De aici a venit acest studiu.
A doua abordare importantă este ca clientul să se angajeze imediat la o scalare adecvată. Aici puteți cumpăra un server suplimentar și puteți adăuga o fermă, de exemplu, pentru 100 de utilizatori, totul este previzibil la prețul de utilizator. De exemplu, atunci când trebuie să adauge încă 300 de utilizatori, vor ști că au nevoie de două servere într-o configurație deja definită, mai degrabă decât să-și reconsidere actualizarea întregii infrastructuri.
Posibilitățile federației HPE SimpliVity sunt interesante. Afacerea este separată geografic, așa că este logic să vă instalați propriul hardware VDI separat într-un birou îndepărtat. În federația SimpliVity, fiecare mașină virtuală este replicată conform unui program cu capacitatea de a se replica între clustere la distanță geografică foarte rapid și fără încărcare pe canal - aceasta este o copie de rezervă încorporată de un nivel foarte bun. La replicarea VM-urilor între site-uri, canalul este utilizat cât mai puțin posibil, iar acest lucru face posibilă construirea de arhitecturi DR foarte interesante în prezența unui singur centru de control și a unei grămadă de site-uri de stocare descentralizate.
Toate acestea împreună fac posibilă evaluarea laturii financiare în detaliu și suprapunerea costurilor VDI pe planurile de creștere ale companiei și înțelegerea cât de repede va fi rentabil soluția și cum va funcționa. Pentru că orice VDI este o soluție care în cele din urmă economisește o mulțime de resurse, dar în același timp, cel mai probabil, fără oportunitatea rentabilă de a-l schimba în 5-7 ani de utilizare.
În general, dacă aveți întrebări care nu sunt de comentat, scrieți-mi pe e-mail [e-mail protejat].
Sursa: www.habr.com