Il cliente ha voluto VDI. Ha esaminato attentamente la combinazione SimpliVity + VDI Citrix Virtual Desktop. Per tutti gli operatori, dipendenti degli uffici in diverse città e così via. Ci sono cinquemila utenti solo nella prima fase di migrazione, e quindi hanno insistito per eseguire test di carico. Il VDI può iniziare a rallentare, può anche andare in crash – e non sempre ciò accade a causa di problemi con la banda. Abbiamo acquistato un pacchetto di test molto potente specificamente per VDI e abbiamo stressato l'infrastruttura fino a farla cadere in termini di dischi e CPU.
Quindi, avremo bisogno di una bottiglia di plastica e del software LoginVSI per test VDI avanzati. Abbiamo una licenza per 300 utenti. Poi abbiamo preso l'hardware HPE SimpliVity 380 in configurazione adeguata per massimizzare la densità degli utenti su un singolo server, abbiamo creato macchine virtuali con buona ridondanza, installato software per l'ufficio su Win10 e iniziato a testare.
Andiamo!
Sistema
Due nodi (server) HPE SimpliVity 380 Gen10. Su ciascuno:
- 2 x Intel Xeon Platinum 8170 26c 2.1Ghz.
- Memoria RAM: 768GB, 12 x 64GB LRDIMMs DDR4 2666MHz.
- Controller disco principale: HPE Smart Array P816i-a SR Gen10.
- Dischi rigidi: 9 x 1.92 TB SATA 6Gb/s SSD (in configurazione RAID6 7+2, ovvero questo modello è Medium in termini di HPE SimpliVity).
- Schede di rete: 4 x 1Gb Eth (dati degli utenti), 2 x 10Gb Eth (back-end SimpliVity e vMotion).
- Schede FPGA integrate in ogni nodo per deduplica/compressione.
I nodi sono collegati tra loro tramite un interconnessione 10Gb Ethernet direttamente senza uno switch esterno, che è utilizzato come back-end SimpliVity e per il trasferimento dei dati delle macchine virtuali tramite NFS. I dati delle macchine virtuali nel cluster sono sempre mirrorati tra i due nodi.
I nodi sono uniti in un cluster Vmware vSphere gestito da vCenter.
Sono stati implementati un controller di dominio e un broker di connessione Citrix per eseguire i test. Il controller di dominio, il broker e vCenter sono stati spostati in un cluster separato.
Come infrastruttura di test sono stati dispiegati 300 desktop virtuali in configurazione Dedicated – Full Copy, ovvero ogni desktop rappresenta una copia completa dell'immagine originale della macchina virtuale e conserva tutte le modifiche apportate dagli utenti.
Ogni macchina virtuale ha 2vCPU e 4GB di RAM:
Sulle macchine virtuali è stato installato il seguente software necessario per eseguire il test:
- Windows 10 (64-bit), versione 1809.
- Adobe Reader XI.
- Citrix Virtual Delivery Agent 1811.1.
- Doro PDF 1.82.
- Java 7 Aggiornamento 13.
- Microsoft Office Professional Plus 2016.
Tra i nodi c'è una replica sincrona. Ogni blocco dati nel cluster ha due copie. Ciò significa che attualmente è presente un set completo di dati su ciascuno dei nodi. Con un cluster di tre nodi o più, le copie dei blocchi si trovano in due posizioni diverse. Quando viene creata una nuova VM, viene creata un'ulteriore copia su uno dei nodi del cluster. Se un nodo si guasta, tutte le VM che erano in esecuzione su di esso vengono automaticamente riavviate su altri nodi, dove hanno delle repliche. Se un nodo è fuori uso per lungo tempo, inizia un recupero graduale della ridondanza e il cluster torna a una configurazione N+1.
Il bilanciamento e la memorizzazione dei dati avvengono a livello dello storage software stesso di SimpliVity.
Le macchine virtuali avviano un cluster di virtualizzazione, che le posiziona nello storage software. I desktop sono stati configurati seguendo modelli standard: per il test sono stati utilizzati desktop per finanzieri e operatori (questi sono due modelli diversi).
Test
Per condurre i test è stato utilizzato il complesso di software LoginVSI 4.1. Il complesso LoginVSI, composto da un server di gestione e 12 macchine per connessioni di test, è stato distribuito su un host fisico separato.
I test sono stati effettuati in tre modalità:
Modalità Benchmark — carichi di lavoro di 300 Knowledge workers e 300 Storage workers.
Modalità Standard — carico di lavoro di 300 Power workers.
Per consentire il funzionamento dei Power workers e aumentare la varietà dei carichi nel complesso LoginVSI è stata aggiunta una libreria di file aggiuntivi, Power Library. Per garantire la ripetibilità dei risultati, tutte le impostazioni del banco di prova sono state lasciate su Default.
I test per i Knowledge e Power workers simulano il carico reale degli utenti che lavorano su stazioni di lavoro virtuali.
Il test per gli Storage workers è stato creato specificamente per testare i sistemi di storage e dista da carichi reali, consistendo per lo più nel lavoro dell'utente con un numero elevato di file di diverse dimensioni.
Durante il processo di test, gli utenti accedono alle stazioni di lavoro per 48 minuti, circa un utente ogni 10 secondi.
Risultati
Il risultato principale del test LoginVSI è la metrica VSImax, che viene calcolata dal tempo di esecuzione di vari compiti eseguiti dall'utente. Ad esempio: il tempo di apertura di un file in Notepad, il tempo di compressione di un file in 7-Zip, e così via.
Una descrizione dettagliata del calcolo delle metriche è disponibile nella documentazione ufficiale di .
In altre parole, LoginVSI replica un modello di carico tipico, simulando le azioni dell'utente con un pacchetto di produttività, durante la lettura di PDF e così via, e misura vari ritardi. Esiste un livello critico di ritardi "tutto si blocca, non è possibile lavorare", fino a raggiungere il quale si considera che il numero massimo di utenti non sia stato raggiunto. Se il tempo di risposta è superiore a 1.000 ms rispetto a questo stato di "tutto si blocca", si ritiene che il sistema funzioni normalmente e si possono aggiungere altri utenti.
Ecco le metriche principali:
Metrica
Azioni eseguite
Dettagliata descrizione
Componenti in carico
NSLD
Tempo di apertura di un file di testo
di dimensioni 1.500 KB
Si avvia Notepad e
apre un documento casuale di 1.500 KB, copiato dal pool
delle risorse
CPU e I/O
NFO
Tempo per aprire la finestra di dialogo
apertura del file VSI-Notepad [Ctrl+O]
CPU, RAM e I/O
ZHC*
Tempo di creazione di un file Zip con elevata compressione
Compressione di un file casuale locale in formato .pst di 5MB, copiato da
un pool di risorse
ZLC*
Tempo di creazione di un file Zip con bassa compressione
CPU e I/O
I/O
Calcolo di un ampio
un pool di risorse
ZLC*
Tempo di creazione di un file Zip con bassa compressione
array di dati casuali
CPU
Creazione di un vasto array
di dati casuali che verranno utilizzati in un timer di input-output (timer I/O)
Durante i test, inizialmente si calcola la metrica di base VSIbase, che mostra la velocità di esecuzione dei compiti senza carico sul sistema. Su questa base si determina il VSImax Threshold, pari a VSIbase + 1.000 ms.
Le conclusioni sulle prestazioni del sistema sono basate su due metriche: VSIbase, che determina la velocità operativa del sistema, e VSImax threshold, che determina il numero massimo di utenti che il sistema può sopportare senza degrado significativo.
CPU
300 Knowledge workers benchmark
300 Knowledge workers benchmark
300 Knowledge workers benchmark
I knowledge workers sono utenti che sovraccaricano regolarmente la memoria, la CPU e l'I/O con picchi di carico vari. Il software emula il carico di utenti ufficio esigenti, come se stessero continuamente interagendo (PDF, Java, pacchetto Office, visualizzazione foto, 7-Zip). Con l'aggiunta di utenti da zero a 300, la latenza di ciascuno aumenta gradualmente.
Statistiche di VSImax:
VSIbase = 986 ms, la soglia VSI non è stata raggiunta.
Statistiche del carico sul sistema di storage dal monitoraggio SimpliVity:
Con questo tipo di carico, il sistema gestisce l'aumento delle richieste praticamente senza degradazione delle prestazioni. Il tempo di esecuzione dei compiti degli utenti cresce gradualmente, il tempo di risposta del sistema non cambia durante il test e arriva fino a 3 ms in scrittura e fino a 1 ms in lettura.
Conclusione: 300 knowledge workers operano senza alcun problema sul cluster attuale e non si disturbano a vicenda, raggiungendo una sovrascrittura pCPU/vCPU di 1 a 6. Le latenze complessive aumentano uniformemente con l'aumento del carico, ma non è stato raggiunto il limite prestabilito.
Benchmark di 300 Storage workers
Questi utenti scrivono e leggono continuamente in un rapporto di 30 a 70 rispettivamente. Questo test è stato condotto più come esperimento. Statistiche di VSImax:
VSIbase = 1673, la soglia VSI è stata raggiunta con 240 utenti.
Statistiche del carico sul sistema di storage dal monitoraggio SimpliVity:
Questo tipo di carico è essenzialmente un test di stress sul sistema di storage. Durante la sua esecuzione, ogni utente scrive su disco numerosi file casuali di dimensioni diverse. In questo caso, si osserva che al superamento di una certa soglia di carico, alcuni utenti mostrano un aumento del tempo di esecuzione dei compiti di scrittura dei file. Tuttavia, il carico sul sistema di storage, sulla CPU e sulla memoria degli host non cambia sostanzialmente, rendendo impossibile al momento determinare con certezza la causa delle latenze.
Le conclusioni sulle prestazioni del sistema da questo test possono essere fatte solo in confronto con i risultati di test su altri sistemi, poiché tali carichi sono sintetici e irrealistici. Tuttavia, in generale, il test è andato abbastanza bene. Fino a 210 sessioni tutto è proceduto senza problemi, dopo di che sono iniziati riscontri imprecisati, che nel frattempo non sono stati monitorati da nessun'altra parte, se non da Login VSI.
300 Power workers
Questi sono utenti che amano il processore, la memoria e alti IO. Questi «utenti avanzati» eseguono regolarmente compiti complessi con picchi prolungati, come l'installazione di nuovo software e l'estrazione di grandi archivi. Dati statistici VSImax:
VSIbase = 970, il limite VSI non è stato raggiunto.
Statistiche del carico sul sistema di storage dal monitoraggio SimpliVity:
Nel test è stata raggiunta la soglia di carico dei processori su uno dei nodi del sistema, ma ciò non ha avuto un impatto significativo sul suo funzionamento:
In questo caso, il sistema sopporta l'aumento del carico senza una significativa degradazione delle prestazioni. Il tempo di esecuzione dei compiti degli utenti aumenta gradualmente, il tempo di risposta del sistema non cambia durante il test e si attesta fino a 3 ms per la scrittura e fino a 1 ms per la lettura.
I test standard non erano sufficienti per il cliente, quindi siamo andati oltre: abbiamo aumentato le caratteristiche della VM (numero di vCPU, per valutare l'aumento della sovrascrittura e la dimensione del disco) e abbiamo aggiunto un carico supplementare.
Durante i test aggiuntivi è stata utilizzata la seguente configurazione del banco di prova:
Sono stati distribuiti 300 desktop virtuali con configurazione 4vCPU, 4GB RAM, 80GB HDD.
Configurazione di una delle macchine di test:
Le macchine sono state distribuite in modalità Dedicated – Full Copy:
300 Knowledge workers benchmark con sovrascrittura 12
Statistiche di VSImax:
VSIbase = 921 ms, il limite VSI non è stato raggiunto.
Statistiche del carico sul sistema di storage dal monitoraggio SimpliVity:
I risultati ottenuti sono analoghi a quelli del test della configurazione precedente della VM.
300 Power workers con sovrascrittura 12
Statistiche di VSImax:
VSIbase = 933, il limite VSI non è stato raggiunto.
Statistiche del carico sul sistema di storage dal monitoraggio SimpliVity:
In questo test è stata raggiunta anche la soglia di carico dei processori, ma ciò non ha avuto un impatto significativo sulle prestazioni:
I risultati ottenuti sono analoghi a quelli del test della configurazione precedente.
Cosa succederà se avviamo un carico per 10 ore?
Ora vediamo se ci sarà un «effetto accumulo» e avviamo test per 10 ore consecutivamente.
I test prolungati e la descrizione della sezione dovrebbero mirare a verificare se si presenteranno eventuali problemi con il server sotto carico prolungato.
300 Knowledge workers benchmark + 10 ore
È stato inoltre condotto un test di carico con 300 knowledge workers seguito da un'attività degli utenti per 10 ore.
Statistiche di VSImax:
VSIbase = 919 ms, il limite VSI non è stato raggiunto.
Dati statistici VSImax Dettagliati:
Dal grafico si evince che durante tutto il test non si osserva alcuna degradazione delle prestazioni.
Statistiche del carico sul sistema di storage dal monitoraggio SimpliVity:
Le prestazioni del sistema di storage rimangono costanti per tutta la durata del test.
Test aggiuntivo con carico sintetico
Il cliente ha richiesto di aggiungere un carico casuale sul disco. Per fare questo, è stato aggiunto un task di avvio di carico sintetico su disco a ciascuna delle macchine virtuali degli utenti all'accesso al sistema. Il carico era fornito dall'utility fio, che consente di limitare il carico sul disco in base al numero di IOPS. In ciascuna macchina veniva avviato un task di carico aggiuntivo di 22 IOPS 70 %/30 % Lettura/Scrittura Casuale.
300 Knowledge workers benchmark + 22 IOPS per utente
Durante i test iniziali, è stato riscontrato che fio crea un carico aggiuntivo significativo sulla CPU delle macchine virtuali. Ciò ha portato a un rapido sovraccarico degli host per CPU e ha influenzato notevolmente il funzionamento del sistema nel suo complesso.
Carico sulla CPU degli host:
Le latenze del sistema di storage sono aumentate di conseguenza:
La mancanza di potenza di calcolo è diventata critica intorno ai 240 utenti:
A seguito dei risultati ottenuti, è stato deciso di condurre un test meno impegnativo per la CPU.
230 Office workers benchmark + 22 IOPS per utente
Per ridurre il carico sulla CPU, è stato scelto il tipo di carico Office workers, aggiungendo anche 22 IOPS di carico sintetico a ciascuna sessione.
Il test è stato limitato a 230 sessioni per non superare il carico massimo sulla CPU.
Il test è stato eseguito con il successivo lavoro degli utenti per 10 ore per verificare la stabilità del sistema durante un periodo prolungato con carico vicino al massimo.
Statistiche di VSImax:
VSIbase = 918 ms, la soglia VSI non è stata raggiunta.
Dati statistici VSImax Dettagliati:
Dal grafico si evince che durante tutto il test non si osserva alcuna degradazione delle prestazioni.
Dati statistici sul carico della CPU:
Durante l'esecuzione di questo test, il carico sulla CPU degli host era praticamente al massimo.
Statistiche del carico sul sistema di storage dal monitoraggio SimpliVity:
Le prestazioni del sistema di storage rimangono costanti per tutta la durata del test.
Il carico sul sistema di storage durante il test è stato di circa 6.500 IOPS con un rapporto 60/40 (3.900 IOPS – per lettura, 2.600 IOPS – per scrittura), che corrisponde a circa 28 IOPS per stazione di lavoro.
Il tempo di risposta medio era di 3 ms per scrittura e fino a 1 ms per lettura.
Risultato
Nella simulazione di carichi reali sull'infrastruttura HPE SimpliVity sono stati ottenuti risultati che confermano la capacità del sistema di supportare il funzionamento di almeno 300 macchine Full Clone su un paio di nodi SimpliVity. In questo processo, il tempo di risposta del sistema di archiviazione è rimasto a un livello ottimale per tutta la durata del test.
Siamo molto colpiti dall'approccio ai test prolungati e dal confronto delle soluzioni prima dell'implementazione. Possiamo testare le prestazioni anche per i vostri carichi, se lo desiderate. Include anche altri solutions iperconvergenti. Il cliente menzionato sta attualmente concludendo i test su un'altra soluzione in parallelo. La sua infrastruttura attuale è semplicemente un parco di PC, un dominio e software su ogni workstation. Trasferirsi su VDI senza test, chiaramente, è abbastanza difficile. È specificamente complicato comprendere le reali capacità della fattoria VDI senza trasferire veri utenti. E questi test permettono di valutare rapidamente le reali capacità di un sistema senza la necessità di coinvolgere utenti comuni. Da qui è emersa tale ricerca.
Un secondo approccio importante è che il cliente ha immediatamente previsto una corretta scalabilità. In questo caso, è possibile acquistare un server in più e aggiungere una fattoria, ad esempio, per 100 utenti, tutto prevedibile nel prezzo per utente. Ad esempio, quando avranno bisogno di aggiungere altri 300 utenti, sapranno che serviranno due server in una configurazione già definita, invece di rivedere le possibilità di aggiornamento della loro infrastruttura in generale.
Sono interessanti le possibilità di federazione di HPE SimpliVity. Il business è geograficamente distribuito, quindi ha senso installare un proprio sistema VDI separato in una sede remota. Nella federazione SimpliVity, ogni virtual machine viene replicata secondo un programma con la possibilità di effettuare trasferimenti tra cluster geograficamente distanti in modo molto veloce e senza carico sulla banda — si tratta di un backup integrato di un livello molto buono. Durante la replicazione della VM tra i siti, la banda viene utilizzata nel modo più minimale possibile, e questo offre la possibilità di costruire architetture DR molto interessanti con un centro di gestione unico e molteplici siti di archiviazione decentralizzati.
Tutto ciò permette di valutare in dettaglio sia l'aspetto finanziario, sia di accostare i costi del VDI ai piani di crescita dell'azienda e di comprendere quanto velocemente si ripagherà la soluzione e come funzionerà. Perché ogni VDI è una soluzione che alla fine consuma molte risorse, ma molto probabilmente, senza la possibilità economicamente vantaggiosa di cambiarla nell'arco di 5-7 anni di utilizzo.
In generale, se hai domande non per commenti, - scrivimi via email a mk@croc.ru.
Fonte: habr.com
