U cliente vulia VDI. Aghju veramente guardatu a cumminazione SimpliVity + VDI Citrix Virtual Desktop. Per tutti l'operatori, l'impiegati di l'uffiziu di a cità, è cusì. Ci sò cinque mila utilizatori in a prima onda di migrazione solu, è per quessa insistenu à a prova di carica. VDI pò principià à rallentà, pò esse tranquillamente stendu - è questu ùn hè micca sempre per via di prublemi cù u canali. Avemu compru un pacchettu di teste assai putente specificamente per VDI è caricate l'infrastruttura finu à chì era troppu pisanti nantu à i dischi è u processatore.
Dunque, avemu bisognu di una buttiglia di plastica è di u software LoginVSI per teste VDI sofisticati. L'avemu cù licenze per 300 utilizatori. Dopu avemu pigliatu l'hardware HPE SimpliVity 380 in un pacchettu adattatu per u compitu di a densità massima di l'utilizatori per u servitore, tagliate e macchine virtuali cù una bona abbonazione, installate u software d'uffiziu in Win10 nantu à elli è cuminciaru à pruvà.
Let's go!
sistemu
Dui nodi HPE SimpliVity 380 Gen10 (servitori). À ognunu:
- 2 x Intel Xeon Platinum 8170 26c 2.1Ghz.
- RAM: 768 GB, 12 x 64 GB LRDIMM DDR4 2666 MHz.
- Controller di discu primariu: HPE Smart Array P816i-a SR Gen10.
- Dischi duru: SSD 9 x 1.92 TB SATA 6Gb/s (in cunfigurazione RAID6 7+2, vale à dì questu hè un mudellu Medium in termini di HPE SimpliVity).
- Carte di rete: 4 x 1Gb Eth (dati d'utilizatore), 2 x 10Gb Eth (backend SimpliVity è vMotion).
- Carte FPGA speciale integrate in ogni nodu per a deduplicazione / cumpressione.
I nodi sò cunnessi l'un à l'altru via una interconnessione Ethernet 10Gb direttamente senza un switch esternu, chì hè utilizatu cum'è un backend SimpliVity è per trasferimentu di dati di a macchina virtuale via NFS. I dati di a macchina virtuale in un cluster sò sempre specchiati trà dui nodi.
I nodi sò cumminati in un cluster Vmware vSphere gestitu da vCenter.
Per a prova, un controller di duminiu è un broker di cunnessione Citrix sò stati implementati. U controller di duminiu, u broker è vCenter sò posti nantu à un cluster separatu.
Cum'è una infrastruttura di prova, 300 desktops virtuali sò stati implementati in a cunfigurazione Dedicated - Full Copy, vale à dì, ogni desktop hè una copia cumpleta di l'imaghjina originale di a macchina virtuale è salva tutti i cambiamenti fatti da l'utilizatori.
Ogni macchina virtuale hà 2vCPU è 4GB RAM:
U seguente software necessariu per a prova hè stallatu nantu à e macchine virtuali:
- Windows 10 (64-bit), versione 1809.
- Adobe Reader XI.
- Citrix Virtual Delivery Agent 1811.1.
- Doro PDF 1.82.
- Java 7 Update 13.
- Microsoft Office Professional Plus 2016.
Trà i nodi - replicazione sincrona. Ogni bloccu di dati in u cluster hà duie copie. Questu hè, avà ci hè un inseme cumpletu di dati nantu à ognunu di i nodi. Cù un cluster di trè o più nodi, e copie di blocchi sò in dui posti diffirenti. Quandu crea una nova VM, una copia addiziale hè creata nantu à unu di i nodi di cluster. Quandu un nodu falla, tutte e VM in esecuzione precedente sò riavviate automaticamente in altri nodi induve anu repliche. Se un node falla per un bellu pezzu, allora a risturazione graduale di a redundanza principia, è u cluster torna à N + 1 redundancy.
L'equilibriu è l'almacenamiento di dati si trovanu à u livellu di almacenamiento di software di SimpliVity stessu.
E macchine virtuali eseguite un cluster di virtualizazione, chì li mette ancu in u almacenamentu di software. I desks stessi sò stati pigliati secondu un mudellu standard: i desks di i finanzieri è l'ufficiali di l'operazioni sò vinuti per a prova (questi sò dui mudelli diffirenti).
Prucessioni
Per a prova, a suite di test di u software LoginVSI 4.1 hè stata utilizata. U cumplessu LoginVSI, custituitu da un servitore di cuntrollu è macchine 12 per e cunnessione di prova, sò stati implementati in un host fisicu separatu.
A prova hè stata fatta in trè modi:
Modu Benchmark - Casi di carica 300 travagliadori di cunniscenza è 300 travagliadori di Storage.
Modu standard - casu di carica 300 travagliadori Power.
Per permette à i travagliadori di Power di travaglià è di aumentà a diversità di carica, una biblioteca di schedarii Power Library addiziunali hè stata aghjunta à u cumplessu LoginVSI. Per assicurà a ripetibilità di i risultati, tutti i paràmetri di u bancu di prova sò stati lasciati cum'è Default.
I testi di i travagliadori di Cunniscenza è Potenza simulanu a vera carica di travagliu di l'utilizatori chì travaglianu in stazioni di travagliu virtuale.
A prova di i travagliadori di Storage hè stata creata apposta per pruvà i sistemi di almacenamentu di dati; hè luntanu da i carichi di travagliu reali è implica principalmente l'utilizatori chì travaglianu cù un gran numaru di fugliali di diverse dimensioni.
Durante a prova, l'utilizatori accede à stazioni di travagliu per 48 minuti à un ritmu di circa un utilizatore ogni 10 seconde.
Risultati
U risultatu principale di a prova di LoginVSI hè a metrica VSImax, chì hè cumpilata da u tempu d'esekzione di diverse attività lanciate da l'utilizatore. Per esempiu: tempu per apre un schedariu in Notepad, tempu per cumpressà un schedariu in 7-Zip, etc.
Una descrizzione dettagliata di u calculu di metrica hè dispunibule in a documentazione ufficiale per .
In altri palori, LoginVSI ripete un mudellu di carica tipica, simula l'azzioni di l'utilizatori in una suite d'uffiziu, leghje un PDF, è cusì, è misurà diverse latenze. Ci hè un livellu criticu di ritardu "tuttu rallenta, hè impussibile di travaglià"), prima di quale hè cunsideratu chì u numeru massimu di utilizatori ùn hè micca ghjuntu. Se u tempu di risposta hè 1 000 ms più veloce di questu statu "tuttu hè lentu", u sistema hè cunsideratu cum'è u travagliu nurmale, è più utilizatori ponu esse aghjuntu.
Eccu i principali metrichi:
Metriche
Azzione pigliata
Detailed Описание
Cumpunenti caricati
N.S.L.D.
Tempu di apertura di u testu
schedariu chì pesa 1 KB
Notepad si apre è
apre un documentu aleatoriu di 1 KB chì hè copiatu da a piscina
risorse
CPU è I/O
NFO
Ora di apertura di dialogu
Windows in blocco note
Apertura di un schedariu VSI-Notepad [Ctrl+O]
CPU, RAM è I/O
ZHC*
U tempu di creà un schedariu Zip altamente cumpressu
Cumpressione locale
5MB aleatoriu .pst file copiatu da
pool di risorse
CPU è I/O
ZLC*
Hè u tempu di creà un schedariu Zip pocu cumpressu
Cumpressione locale
5MB aleatoriu .pst file copiatu da
pool di risorse
I / O
CPU
Calculà grande
matrice di dati aleatoriu
Crià un grande array
dati aleatorii chì seranu utilizati in u timer di input / output (timer I / O)
CPU
Quandu a prova hè realizata, a metrica di basa VSIbase hè inizialmente calculata, chì mostra a velocità à quale i travaglii sò eseguiti senza carica nantu à u sistema. Basatu nantu à questu, u VSImax Threshold hè determinatu, chì hè uguali à VSIbase + 1ms.
I cunclusioni nantu à u funziunamentu di u sistema sò basati nantu à duie metriche: VSIbase, chì determina a velocità di u sistema, è VSImax threshold, chì determina u numeru massimu di utilizatori chì u sistema pò trattà senza degradazione significativa.
Benchmark di 300 travagliadori di cunniscenza
I travagliadori di a cunniscenza sò utilizatori chì caricanu regularmente memoria, processore è IO cù diversi picculi picculi. U software emula a carica di travagliu di l'utilizatori di l'uffiziu esigenti, cum'è s'elli eranu constantemente chjappà qualcosa (PDF, Java, suite d'uffiziu, visualizazione di foto, 7-Zip). Quandu aghjunghje l'utilizatori da zero à 300, u ritardu per ognunu aumenta gradualmente.
Dati di statistiche VSImax:
VSIbase = 986ms, VSI Threshold ùn hè micca righjuntu.
Statistiche di carica di u sistema di almacenamentu da u monitoraghju SimpliVity:
Cù stu tipu di carica, u sistema pò sustene a carica aumentata senza praticamente alcuna degradazione in u rendiment. U tempu chì ci vole à cumplettà i travaglii di l'utilizatori aumenta in modu fluidu, u tempu di risposta di u sistema ùn cambia micca durante a prova è hè finu à 3 ms per scrive è finu à 1 ms per leghje.
Cunsigliu: L'utilizatori di cunniscenze 300 travaglianu nantu à u cluster attuale senza alcunu prublema è ùn interferiscenu micca l'una cù l'altru, righjunghjendu u oversubscription pCPU / vCPU di 1 à 6. I ritardi in generale crescenu in modu uniformu cum'è a carica aumenta, ma u limitu stipulatu ùn hè micca righjuntu.
Benchmark di 300 travagliadori di Storage
Quessi sò utilizatori chì scrivenu è leghje constantemente in una proporzione di 30 à 70, rispettivamente. Questa prova hè stata realizata più per l'esperimentu. Dati di statistiche VSImax:
VSIbase = 1673, VSI Threshold righjuntu nantu à 240 utilizatori.
Statistiche di carica di u sistema di almacenamentu da u monitoraghju SimpliVity:
Stu tipu di carica hè essenzialmente una prova di stress di u sistema di almacenamento. Quandu hè eseguitu, ogni utilizatore scrive parechji schedarii aleatorii di diverse dimensioni à u discu. In questu casu, si pò vede chì quandu un certu limitu di carica hè superatu per certi utilizatori, u tempu chì ci vole à compie i travaglii di scrittura di schedari aumenta. À u listessu tempu, a carica nantu à u sistema di almacenamiento, u processatore è a memoria di l'ospiti ùn cambia micca significativamente, per quessa, hè attualmente impussibile di determinà esattamente ciò chì hè causatu i ritardi.
Cunclusioni nantu à u rendiment di u sistema cù sta prova pò esse fatta solu in paragunà cù i risultati di teste in altri sistemi, postu chì tali carichi sò sintetici è irrealistici. Tuttavia, in generale, a prova hè andata bè. Tuttu hè andatu bè finu à 210 sessioni, è dopu avè principiatu risposti strani, chì ùn sò stati tracciati in ogni locu, salvu Login VSI.
300 travagliadori di putenza
Quessi sò utilizatori chì amanu CPU, memoria è IO altu. Questi "utenti di putenza" currianu regularmente compiti cumplessi cù lunghi bursts, cum'è installà un novu software è unpacking grandi archivi. Dati di statistiche VSImax:
VSIbase = 970, VSI Threshold ùn hè micca righjuntu.
Statistiche di carica di u sistema di almacenamentu da u monitoraghju SimpliVity:
Durante a prova, u limitu di carica di u processatore hè statu righjuntu nantu à unu di i nodi di u sistema, ma questu ùn hà micca un impattu significativu in u so funziunamentu:
In questu casu, u sistema pò sustene a carica aumentata senza una degradazione significativa di u rendiment. U tempu chì ci vole à cumplettà i travaglii di l'utilizatori aumenta in modu fluidu, u tempu di risposta di u sistema ùn cambia micca durante a prova è hè finu à 3 ms per scrive è finu à 1 ms per leghje.
I testi rigulari ùn sò micca abbastanza per u cliente, è andemu più in là: avemu aumentatu e caratteristiche di VM (numeru di vCPU per valutà l'aumentu di l'oversubscription è a dimensione di u discu) è aghjunghjemu carica supplementu.
Quandu anu realizatu teste supplementari, a seguente cunfigurazione di stand hè stata aduprata:
300 desktop virtuali sò stati implementati in una cunfigurazione 4vCPU, 4GB RAM, 80GB HDD.
Configurazione di una di e macchine di prova:
E macchine sò implementate in l'opzione Dedicata - Copia completa:
Benchmark di 300 travagliadori di cunniscenza cù oversubscription 12
Dati di statistiche VSImax:
VSIbase = 921 ms, VSI Threshold ùn hè micca righjuntu.
Statistiche di carica di u sistema di almacenamentu da u monitoraghju SimpliVity:
I risultati ottenuti sò simili à pruvà a cunfigurazione VM precedente.
300 travagliadori Power cun 12 oversubscriptions
Dati di statistiche VSImax:
VSIbase = 933, VSI Threshold ùn hè micca righjuntu.
Statistiche di carica di u sistema di almacenamentu da u monitoraghju SimpliVity:
Duranti sta prova, u limitu di carica di u processatore hè statu ancu righjuntu, ma questu ùn hà micca un impattu significativu in u rendiment:
I risultati ottenuti sò simili à a prova di a cunfigurazione precedente.
Chì succèri sè vo eseguite a carica per 10 ore?
Avà vede s'ellu ci sarà un "effettu d'accumulazione" è eseguite teste per 10 ore in una fila.
I testi à longu andà è a descrizzione di a rùbbrica deve esse destinatu à u fattu chì avemu vulsutu verificà s'ellu ci sò prublemi cù u truss sottu una carica prolongata.
Benchmark di 300 travagliadori di cunniscenza + 10 ore
Inoltre, un casu di carica di 300 travagliadori di cunniscenza hè statu pruvatu, seguitu da u travagliu di l'utilizatori per 10 ore.
Dati di statistiche VSImax:
VSIbase = 919 ms, VSI Threshold ùn hè micca righjuntu.
VSImax Dati statistici detallati:
U graficu mostra chì ùn ci hè nisuna degradazione di u rendiment osservata in tuttu u test.
Statistiche di carica di u sistema di almacenamentu da u monitoraghju SimpliVity:
U rendiment di u sistema di almacenamentu resta u listessu in tutta a prova.
Test supplementari cù l'aghjunzione di carica sintetica
U cliente hà dumandatu à aghjunghje una carica salvatica à u discu. Per fà questu, un compitu hè statu aghjuntu à u sistema di almacenamiento in ogni macchina virtuale di l'utilizatori per eseguisce una carica sintetica nantu à u discu quandu l'utilizatore accede à u sistema. A carica hè stata furnita da l'utilità fio, chì permette di limità a carica nantu à u discu da u numeru di IOPS. In ogni macchina, hè stata lanciata un compitu per lancià una carica addiziale in quantità di 22 IOPS 70% / 30% Random Read/Write.
Benchmark di 300 travagliadori di cunniscenza + 22 IOPS per utilizatore
In a prova iniziale, fio hè stata trovata per impone un overhead di CPU significativu nantu à e macchine virtuali. Questu hà purtatu à una rapida sopracarga di CPU di l'ospiti è hà assai influinzatu l'operazione di u sistema in tuttu.
Carica CPU host:
À u listessu tempu, i ritardi di u sistema di almacenamentu anu ancu naturalmente aumentatu:
A mancanza di putenza informatica hè diventata critica intornu à 240 utilizatori:
A causa di i risultati ottenuti, hè statu decisu di fà una prova chì era menu intensiva di CPU.
230 Office Workers benchmark + 22 IOPS per utilizatore
Per riduce a carica nantu à u CPU, u tipu di carica di i travagliadori Office hè statu sceltu, è 22 IOPS di carica sintetica sò stati ancu aghjuntu à ogni sessione.
A prova hè stata limitata à 230 sessioni per ùn superà a carica massima di CPU.
A prova hè stata eseguita cù l'utilizatori chì currenu per 10 ore per verificà a stabilità di u sistema durante l'operazione à longu andà vicinu à a carica massima.
Dati di statistiche VSImax:
VSIbase = 918 ms, VSI Threshold ùn hè micca righjuntu.
VSImax Dati statistici detallati:
U graficu mostra chì ùn ci hè nisuna degradazione di u rendiment osservata in tuttu u test.
Statistiche di carica di CPU:
Quandu eseguisce sta prova, a carica nantu à u CPU di l'ospiti era quasi massima.
Statistiche di carica di u sistema di almacenamentu da u monitoraghju SimpliVity:
U rendiment di u sistema di almacenamentu resta u listessu in tutta a prova.
A carica nantu à u sistema di almacenamiento durante a prova era di circa 6 500 IOPS in un rapportu 60/40 (3 900 IOPS in lettura, 2 600 IOPS in scrittura), chì hè circa 28 IOPS per stazione di travagliu.
U tempu di risposta hè in media di 3 ms per a scrittura è finu à 1 ms per a lettura.
U risultatu
Quandu si simulanu carichi reali nantu à l'infrastruttura HPE SimpliVity, i risultati sò stati ottenuti cunfirmendu a capacità di u sistema di supportà i desktop virtuali di almenu 300 macchine Full Clone in un paru di nodi SimpliVity. À u listessu tempu, u tempu di risposta di u sistema di almacenamentu hè statu mantinutu à un livellu ottimali in tuttu u testu.
Semu assai impressiunati da l'approcciu di teste longu è paraguni di suluzioni prima di implementazione. Pudemu ancu pruvà a prestazione per i vostri carichi di travagliu se vulete. Includendu altre soluzioni hyperconverged. U cliente mintuatu hè avà finitu teste nantu à una altra suluzione in parallelu. A so infrastruttura attuale hè solu una flotta di PC, un duminiu è software in ogni locu di travagliu. Passà à VDI senza teste hè, sicuru, abbastanza difficiule. In particulare, hè difficiule di capiscenu e capacità reali di una splutazioni VDI senza migrazione di l'utilizatori veri à questu. E sti testi permettenu di valutà rapidamente e capacità reali di un sistema particulari senza a necessità di participà à l'utilizatori ordinali. Questu hè induve stu studiu hè vinutu.
U sicondu approcciu impurtante hè chì u cliente s'impegna subitu à a scala propria. Quì pudete cumprà un servitore supplementu è aghjunghje una splutazioni, per esempiu, per l'utilizatori 100, tuttu hè prevedibile à u prezzu di l'utilizatori. Per esempiu, quandu anu bisognu di aghjunghje 300 utilizatori più, sanu chì anu bisognu di dui servitori in una cunfigurazione digià definita, piuttostu cà ricunsiderà l'aghjurnamentu di a so infrastruttura sana.
E pussibulità di a federazione HPE SimpliVity sò interessanti. L'affari hè geograficamente separatu, cusì hè sensu per installà u vostru propiu hardware VDI separatu in un uffiziu distante. In a federazione SimpliVity, ogni macchina virtuale hè replicata secondu un schedariu cù a capacità di riplicà trà clusters geograficamente remoti assai rapidamente è senza carica nantu à u canali - questu hè una copia di salvezza integrata di un livellu assai bonu. Quandu si riplicanu VM trà i siti, u canali hè utilizatu u più minimu pussibule, è questu permette di custruisce architetture DR assai interessanti in a presenza di un centru di cuntrollu unicu è una mansa di siti di almacenamiento descentralizati.
Tuttu chistu inseme permette di valutà a parte finanziaria in grande dittagli, è di superpose i costi di VDI nantu à i piani di crescita di a cumpagnia, è di capisce quantu prestu a suluzione pagarà è cumu si travaglià. Perchè ogni VDI hè una suluzione chì ultimamente salva assai risorse, ma à u stessu tempu, assai prubabilmente, senza l'uppurtunità di costu di cambià in 5-7 anni di usu.
In generale, sè vo avete qualchì quistione chì ùn sò micca per cummentarii, scrivitemi per email [email prutettu].
Source: www.habr.com