Il cliente desiderava VDI. Era molto interessato alla combinazione SimpliVity + VDI Citrix Virtual Desktop. Per tutti gli operatori, i dipendenti degli uffici nelle città, e così via. Ci sono cinquemila utenti solo nella prima fase della migrazione, e quindi hanno insistito sui test di carico. VDI può iniziare a rallentare, può tranquillamente bloccarsi — e non sempre questo avviene a causa di problemi con il canale. Abbiamo acquistato un pacchetto di test molto potente specificamente per VDI e abbiamo stressato l'infrastruttura fino a quando non è andata in panne a causa dei dischi e della CPU.
Quindi, avremo bisogno di una bottiglia di plastica, del software LoginVSI per test VDI avanzati. Abbiamo questo software con licenze per 300 utenti. Poi abbiamo preso l'hardware HPE SimpliVity 380 con una configurazione adatta per massimizzare la densità degli utenti su un server, abbiamo suddiviso le macchine virtuali con una buona ridondanza, installato su di esse software per ufficio su Win10 e abbiamo iniziato a testare.
Andiamo!
Sistema
Due nodi (server) HPE SimpliVity 380 Gen10. Ognuno di essi ha:
- 2 x Intel Xeon Platinum 8170 26c 2.1Ghz.
- Memoria RAM: 768GB, 12 x 64GB LRDIMMs DDR4 2666MHz.
- Controller principale dei dischi: HPE Smart Array P816i-a SR Gen10.
- Dischi rigidi: 9 x 1,92 TB SATA 6Gb/s SSD (in configurazione RAID6 7+2, cioè questo modello è Medium in termini di HPE SimpliVity).
- Schede di rete: 4 x 1Gb Eth (dati utenti), 2 x 10Gb Eth (back-end SimpliVity e vMotion).
- Schede FPGA integrate speciali in ogni nodo per deduplicazione/compressione.
I nodi sono connessi tra loro tramite interconnessione 10Gb Ethernet direttamente, senza uno switch esterno, utilizzato come back-end SimpliVity e per il trasferimento dei dati delle macchine virtuali tramite NFS. I dati delle macchine virtuali nel cluster vengono sempre replicati tra due nodi.
I nodi sono uniti in un cluster Vmware vSphere sotto la gestione di vCenter.
Per condurre i test, sono stati distribuiti un controller di dominio e un broker di connessione Citrix. Il controller di dominio, il broker e vCenter sono stati spostati su un cluster separato.
Come infrastruttura di test, sono stati distribuiti 300 desktop virtuali in configurazione Dedicated – Full Copy, cioè ogni desktop rappresenta una copia completa dell'immagine originale della macchina virtuale e conserva tutte le modifiche effettuate dagli utenti.
Ogni macchina virtuale ha 2vCPU e 4GB RAM:
Il seguente software è stato installato sulle macchine virtuali, necessario per eseguire i test:
- 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.
Tra i nodi avviene una replica sincronizzata. Ogni blocco di dati nel cluster ha due copie. Ciò significa che attualmente ogni nodo dispone di un insieme completo di dati. Con un cluster di tre o più nodi, 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. In caso di guasto di un nodo, tutte le VM precedentemente in esecuzione su di esso vengono automaticamente riavviate su altri nodi dove sono presenti le loro repliche. Se un nodo rimane guasto a lungo, inizia il ripristino graduale della ridondanza, e il cluster torna a una configurazione di riserva N+1.
Il bilanciamento e lo stoccaggio 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. Gli stessi desktop sono stati presi da un modello standard: sono stati testati desktop di finanzieri e di operatori (questi sono due modelli diversi).
Test
Per il test è stato utilizzato il complesso software di LoginVSI 4.1. Il complesso LoginVSI, che include un server di gestione e 12 macchine per le connessioni di test, è stato distribuito su un host fisico separato.
I test sono stati eseguiti 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à del carico, è stata aggiunta al complesso LoginVSI la libreria di file aggiuntivi Power Library. Per garantire la ripetibilità dei risultati, tutte le impostazioni del banco di prova sono state lasciate a Default.
I test Knowledge e Power workers simulano il carico reale degli utenti che lavorano su workstation virtuali.
Il test Storage workers è stato creato specificamente per testare i sistemi di archiviazione dei dati, è lontano dai carichi reali e consiste principalmente nel lavoro dell’utente con un gran numero di file di diverse dimensioni.
Durante il test, gli utenti accedono alle workstation per un periodo di 48 minuti, circa un utente ogni 10 secondi.
Risultati
Il principale risultato del test LoginVSI è la metrica VSImax, che si compone del 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, ecc.
Una descrizione dettagliata del calcolo delle metriche è disponibile nella documentazione ufficiale su .
In altre parole, LoginVSI replica un modello di carico tipico, simulando le azioni dell'utente in un pacchetto per ufficio, nella lettura di PDF e così via, e misura vari ritardi. Esiste un livello critico di ritardi ("tutto si blocca, è impossibile lavorare"), che, se raggiunto, indica che il numero massimo di utenti non è stato raggiunto. Se il tempo di risposta è inferiore a 1000 ms rispetto a questa condizione di "tutto si blocca", si considera che il sistema funzioni normalmente e che sia possibile aggiungere ulteriori utenti.
Ecco le principali metriche:
Metrica
Azioni eseguite
Dettagliato descrizione
Componenti caricati
NSLD
Tempo di apertura di un file di testo
di 1 500 Kbyte
Viene avviato Notepad e apre un documento casuale di 1 500 Kbyte, copiato dal pool delle risorse
CPU e I/O
NFO
Tempo di apertura della finestra di dialogo in Notepad
Apertura del file VSI-Notepad [Ctrl+O]
CPU, RAM e I/O
finestre nel blocco note
Apertura del file VSI-Notepad [Ctrl+O]
CPU, RAM e I/O
ZHC*
Tempo di creazione del file Zip con alta compressione
Compressione locale
di un file casuale in formato .pst di 5MB, copiato da
pool di risorse
Tempo di apertura della finestra di dialogo in Notepad
ZLC*
Tempo di creazione del file Zip con bassa compressione
Compressione locale
di un file casuale in formato .pst di 5MB, copiato da
pool di risorse
I/O
CPU
Calcolo di un grande
array di dati casuali
Creazione di un grande array
di dati casuali, che saranno utilizzati nel timer input-output (timer I/O)
CPU
Durante i test, viene inizialmente calcolata la metrica di base VSIbase, che mostra la velocità di esecuzione delle attività senza carico sul sistema. Su questa base viene determinata la soglia VSImax, che è pari a VSIbase + 1.000 ms.
Le conclusioni sulle prestazioni del sistema si basano su due metriche: VSIbase, che definisce la velocità operativa del sistema, e la soglia VSImax, che determina il numero massimo di utenti che il sistema può gestire senza una significativa degradazione.
300 indicatori di prestazione dei lavoratori della conoscenza
I lavoratori della conoscenza sono utenti che caricano regolarmente memoria, CPU e IO con piccoli picchi. Il software emula il carico di utenti d'ufficio esigenti, come se stessero continuamente interagendo (PDF, Java, pacchetto Office, visualizzazione foto, 7-Zip). Man mano che il numero di utenti aumenta da zero a 300, la latenza di ciascuno cresce gradualmente.
Dati delle statistiche VSImax:
VSIbase = 986ms, la soglia VSI non è stata raggiunta.
Statistiche del carico sul sistema di archiviazione dal monitoraggio SimpliVity:
Con questo tipo di carico, il sistema resiste all'aumento del carico praticamente senza degradazione delle prestazioni. Il tempo di esecuzione delle attività degli utenti cresce gradualmente, il tempo di risposta del sistema rimane invariato durante il test, attestandosi fino a 3 ms in scrittura e fino a 1 ms in lettura.
Risultato: 300 lavoratori della conoscenza operano senza alcun problema nel cluster attuale e non si ostacolano a vicenda, raggiungendo una sovrascrittura pCPU/vCPU di 1 a 6. Le latenze totali aumentano uniformemente con l'aumento del carico, ma il limite fissato non è stato raggiunto.
Benchmark di 300 Storage workers
Questi sono utenti che scrivono e leggono continuamente in proporzione 30 a 70 rispettivamente. Questo test è stato condotto più per sperimentazione. Dati statistici VSImax:
VSIbase = 1673, la soglia VSI è stata raggiunta con 240 utenti.
Statistiche del carico sul sistema di archiviazione dal monitoraggio SimpliVity:
Questo tipo di carico è, sostanzialmente, un test di stress del sistema di archiviazione. Durante l'esecuzione, ogni utente scrive su disco numerosi file casuali di diverse dimensioni. In questo caso, si osserva che oltre una certa soglia di carico, parte degli utenti ha un tempo di esecuzione delle operazioni di scrittura dei file più elevato. Tuttavia, il carico sul sistema di archiviazione, sulla CPU e sulla memoria degli host non cambia in modo significativo, quindi al momento non è possibile determinare con precisione a cosa siano collegate le latenza.
Le conclusioni sulle prestazioni del sistema a causa di questo test possono essere formulate solo confrontando i risultati del test su altri sistemi, poiché tali carichi sono sintetici, irrealistici. Tuttavia, in generale, il test è andato abbastanza bene. Fino a 210 sessioni tutto funzionava bene, poi sono iniziati riscontri poco chiari, che non sono stati tracciati altrove, tranne che in Login VSI.
300 Power workers
Questi sono utenti che apprezzano processori, memoria e elevati 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 di VSImax:
VSIbase = 970, la soglia VSI non è stata raggiunta.
Statistiche del carico sul sistema di archiviazione dal monitoraggio SimpliVity:
Durante i test è stata raggiunta la soglia di carico dei processori su uno dei nodi del sistema, ma questo non ha avuto un impatto significativo sulle sue prestazioni:
In questo caso, il sistema sopporta l'aumento del carico senza una significativa degradazione delle prestazioni. I tempi di esecuzione delle attività degli utenti aumentano lentamente, il tempo di risposta del sistema rimane invariato durante i test e ammonta a 3 ms per la scrittura e a 1 ms per la lettura.
I test standard non erano sufficienti per il cliente, e abbiamo deciso di fare di più: abbiamo aumentato le specifiche VM (numero di vCPU, per valutare l'aumento della sovrascrittura e la dimensione del disco) e aggiunto carico supplementare.
Durante i test aggiuntivi è stata utilizzata la seguente configurazione dell'ambiente:
Sono stati implementati 300 desktop virtuali con configurazione 4vCPU, 4GB RAM, 80GB HDD.
Configurazione di una delle macchine di test:
Le macchine sono distribuite nella configurazione Dedicated – Full Copy:
300 Knowledge workers benchmark con sottoscrizione 12
Dati delle statistiche VSImax:
VSIbase = 921 ms, il VSI Threshold non è stato raggiunto.
Statistiche del carico sul sistema di archiviazione dal monitoraggio SimpliVity:
I risultati ottenuti sono simili ai test della configurazione VM precedente.
300 Power workers con sottoscrizione 12
Dati delle statistiche VSImax:
VSIbase = 933, il VSI Threshold non è stato raggiunto.
Statistiche del carico sul sistema di archiviazione dal monitoraggio SimpliVity:
In questo test è stato raggiunto il limite di carico dei processori, ma ciò non ha avuto un impatto significativo sulle prestazioni:
I risultati ottenuti sono simili ai test della configurazione precedente.
Cosa succederà se avviamo il carico per 10 ore?
Ora vediamo se ci sarà 'effetto accumulo', eseguendo test per 10 ore consecutive.
I test prolungati e la descrizione della sezione devono essere focalizzati su ciò che volevamo verificare, se ci sarebbero stati problemi con il sistema sotto carico prolungato.
300 Knowledge workers benchmark + 10 ore
È stato inoltre condotto un test di carico con 300 knowledge workers seguito da 10 ore di lavoro degli utenti.
Dati delle statistiche VSImax:
VSIbase = 919 ms, il VSI Threshold non è stato raggiunto.
Dati statistici VSImax Dettagliati:
Dal grafico si può notare che durante tutto il test non si osserva alcun degrado delle prestazioni.
Statistiche del carico sul sistema di archiviazione dal monitoraggio SimpliVity:
Le prestazioni del sistema di archiviazione rimangono costanti durante tutto il test.
Test aggiuntivi con carico sintetico
Il cliente ha richiesto di aggiungere un carico intenso sul disco. A questo scopo, è stato aggiunto un compito di avvio della carico sintetico sul disco a ciascuna delle macchine virtuali degli utenti al momento dell'accesso. Il carico era gestito dall'utilità fio, che consente di limitare il carico sul disco in base al numero di IOPS. In ciascuna macchina veniva avviato un compito per generare un carico supplementare di 22 IOPS con una distribuzione 70%/30% Random Read/Write.
300 Knowledge workers benchmark + 22 IOPS per utente
Nella fase iniziale del test è emerso che fio generava un carico significativamente maggiore sulla CPU delle macchine virtuali. Questo ha portato a un rapido sovraccarico degli host in termini di CPU, influenzando notevolmente il funzionamento del sistema nel suo insieme.
Carico sulla CPU degli host:
Di conseguenza, anche i ritardi del sistema di archiviazione sono aumentati in modo prevedibile:
La mancanza di potenza di calcolo è diventata critica intorno ai 240 utenti:
In base ai risultati ottenuti, è stata presa la decisione di effettuare un test meno gravoso per la CPU.
230 lavoratori d'ufficio nel benchmark + 22 IOPS per utente
Per ridurre il carico sulla CPU, è stata scelta la tipologia di carico 'lavoratori d'ufficio', e a ciascuna sessione sono stati aggiunti 22 IOPS di carico sintetico.
Il test è stato limitato a 230 sessioni per non superare il carico massimo sulla CPU.
Il test è stato avviato con il successivo lavoro degli utenti per un periodo di 10 ore, al fine di verificare la stabilità del sistema durante un periodo prolungato di lavoro con carico vicino al massimo.
Dati delle statistiche VSImax:
VSIbase = 918 ms, la soglia VSI non è stata raggiunta.
Dati statistici VSImax Dettagliati:
Dal grafico si può notare che durante tutto il test non si osserva alcun degrado delle prestazioni.
Dati delle statistiche sul carico della CPU:
Durante l'esecuzione di questo test, il carico sulla CPU degli host è stato praticamente massimo.
Statistiche del carico sul sistema di archiviazione dal monitoraggio SimpliVity:
Le prestazioni del sistema di archiviazione rimangono costanti durante tutto il test.
Il carico sul sistema di archiviazione durante il test è stato di circa 6.500 IOPS con un rapporto di 60/40 (3.900 IOPS per la lettura, 2.600 IOPS per la scrittura), che corrisponde a circa 28 IOPS per singolo workstation.
Il tempo di risposta medio era di 3 ms per la scrittura e fino a 1 ms per la lettura.
Risultato
Durante la simulazione di carichi reali sull'infrastruttura HPE SimpliVity, sono stati ottenuti risultati che confermano la capacità del sistema di supportare almeno 300 macchine Full Clone su un paio di nodi SimpliVity. Nel contempo, il tempo di risposta del sistema di archiviazione è rimasto a un livello ottimale per tutta la durata del test.
Apprezziamo molto l'approccio ai test prolungati e il confronto delle soluzioni prima dell'implementazione. Possiamo testare le prestazioni anche per i vostri carichi, se lo desiderate. Includendo altre soluzioni iper-convergenti. Il cliente in questione sta attualmente completando i test su un'altra soluzione in parallelo. La sua attuale infrastruttura è semplicemente un parco PC, un dominio e software su ogni postazione di lavoro. Migrare a VDI senza test, naturalmente, è piuttosto difficile. È particolarmente complicato comprendere le reali capacità della fattoria VDI senza aver migrato reali utenti su di essa. Questi test consentono di valutare rapidamente le capacità reali di un sistema senza la necessità di coinvolgere utenti normali. Da qui è nato questo tipo di ricerca.
Il secondo approccio importante è che il cliente ha subito previsto una corretta scalabilità. Qui è possibile acquistare server e aggiungere un cluster, ad esempio, per 100 utenti, con costi prevedibili per utente. Ad esempio, quando dovranno aggiungere altri 300 utenti, sapranno che serviranno due server in una configurazione già definita, senza dover rivedere le possibilità di aggiornamento della propria infrastruttura nel complesso.
Le possibilità di federazione di HPE SimpliVity sono interessanti. Il business è geograficamente distribuito, quindi ha senso installare una propria unità VDI separata in un ufficio remoto. Nella federazione SimpliVity, ogni macchina virtuale viene replicata secondo un piano con la possibilità di operare tra cluster geograficamente distanti in modo molto rapido e senza sovraccaricare la rete — si tratta di un backup integrato di ottimo livello. Durante la replicazione delle VM tra i siti, la rete viene utilizzata nel modo più minimale possibile, e questo consente di costruire architetture DR molto interessanti con un unico centro di gestione e molteplici siti di archiviazione decentralizzati.
Tutto ciò consente di valutare in dettaglio anche l'aspetto finanziario, di sovrapporre i costi del VDI ai piani di crescita dell'azienda e di comprendere quanto rapidamente si ripagherà la soluzione e come funzionerà. Poiché qualsiasi VDI è una soluzione che alla fine fa risparmiare molte risorse, ma probabilmente senza la possibilità economicamente vantaggiosa di cambiarla nei 5-7 anni di utilizzo.
In generale, se hai domande non da scrivere nei commenti, scrivimi via email a mk@croc.ru.
Fonte: habr.com
