Ti sei mai chiesto cosa fa uno scanner con una stazione VDI? All'inizio sembra tutto a posto: viene inoltrato come un normale dispositivo USB ed è visibile “in modo trasparente” dalla macchina virtuale. Quindi l'utente dà il comando di scansionare e tutto va al diavolo. Nel migliore dei casi - il driver dello scanner, nel peggiore dei casi - in un paio di minuti il software dello scanner, quindi può influenzare altri utenti del cluster. Perché? Perché per ottenere un'immagine compressa da cinque megabyte, è necessario inviare da due a tre ordini di grandezza in più di dati tramite USB 2.0. La velocità del bus è di 480 Mbit/s.
Quindi devi testare tre cose: UX, periferiche e sicurezza: un must. C'è una differenza nel modo in cui esegui il test. È possibile installare gli agenti localmente su ciascuna workstation virtuale. Questo è relativamente economico, ma non mostra il carico sul canale e non calcola in modo abbastanza accurato il carico sul processore. La seconda opzione è distribuire il numero richiesto di robot emulatori in un altro luogo e iniziare a collegarli a lavori reali come utenti reali. Verrà aggiunto il carico dal protocollo di trasmissione del flusso video sullo schermo (più precisamente, pixel modificati), l'analisi e l'invio di pacchetti di rete e il carico sul canale diventerà chiaro. Il canale viene generalmente controllato molto raramente.
UX è la velocità con cui l'utente finale esegue varie azioni. Esistono pacchetti di prova che caricano l'installazione con centinaia di utenti ed eseguono azioni tipiche per loro: avviare pacchetti Office, leggere PDF, navigare, guardare raramente porno durante l'orario di lavoro e così via.
Un ottimo esempio del motivo per cui tali test sono importanti in anticipo si trova nell'ultima installazione. Lì mille utenti stanno passando alla VDI, hanno un ufficio, un browser e SAP. Il reparto IT dell'azienda è sviluppato, quindi esiste una cultura del test di carico prima delle implementazioni. Secondo la mia esperienza, di solito bisogna convincere il cliente a farlo, perché i costi sono alti e i benefici non sempre sono evidenti. Ci sono calcoli in cui puoi sbagliare? In effetti, tali test rivelano luoghi in cui hanno pensato, ma non hanno potuto controllare.
installazione
Sei server, la configurazione è:
Non avevamo accesso al sistema di storage del cliente; veniva infatti fornito come un luogo come servizio. Ma sappiamo che esiste l'all-flash. Non sappiamo di quale all-flash si tratti, ma le partizioni sono da 10 TB. VDI - VMware a scelta del cliente, poiché il team IT ha già familiarità con lo stack e tutto è integrato in modo abbastanza organico per formare un'infrastruttura completa. VMware è molto “dipendente” dal suo ecosistema, ma se disponi di un budget sufficiente per gli acquisti, potresti non avere problemi per anni. Ma questo è spesso un “se” molto grande. Abbiamo un buon sconto e il cliente lo sa.
Stiamo iniziando i test, perché il team IT non rilascia quasi nulla in produzione senza test. La VDI non è qualcosa che puoi lanciare e poi accettare. Gli utenti si caricano gradualmente ed è possibile riscontrare problemi dopo sei mesi. Cosa che ovviamente nessuno vuole.
450 “utenti” nel test, il carico viene generato localmente. Gli utenti Robo eseguono azioni diverse contemporaneamente, misuriamo il tempo di ciascuna operazione su diverse ore di lavoro:
Vediamo come si comporteranno i server e i sistemi di storage. VDI sarà in grado di creare il numero richiesto di desktop virtuali e così via. Poiché il cliente non ha seguito la strada dell’iperconvergenza, ma ha adottato un sistema di storage all-flash, è stato necessario verificare anche la correttezza del dimensionamento.
In realtà, se qualcosa rallenta da qualche parte, è necessario modificare le impostazioni della farm VDI, in particolare la distribuzione delle risorse tra utenti di diverse categorie.
periferia
Di solito ci sono tre situazioni con le periferiche:
- Il cliente dice semplicemente che non stiamo collegando nulla (beh, ad eccezione delle cuffie, di solito sono visibili “fuori dalla scatola”). Negli ultimi cinque anni circa, ho visto molto, molto raramente cuffie che non fossero state ritirate da sole e che non fossero state ritirate da VMware.
- Il secondo approccio è quello di prendere e modificare le periferiche come parte del progetto di implementazione VDI: prendiamo ciò che noi e il cliente abbiamo testato e supportato. Il caso è comprensibilmente raro.
- Il terzo approccio consiste nell'utilizzare l'hardware esistente.
Conosci già il problema con gli scanner: devi installare un middleware su una workstation (thin client), che riceve un flusso USB, comprime l'immagine e la invia a VDI. A causa di una serie di caratteristiche, questo non è sempre possibile: se tutto va bene sui client Win (computer domestici e thin client), allora per *nix build il fornitore VDI di solito supporta una distribuzione specifica e iniziano le danze con un tamburello, come sui client Mac. Nella mia memoria, poche persone collegavano stampanti locali da installazioni Linux in modo che potessero lavorare nella fase di debug senza continue chiamate al supporto. Ma questo va già bene, qualche tempo fa, anche solo per lavorare.
Videoconferenza: tutti i clienti prima o poi vogliono che funzioni e funzioni bene. Se la farm è progettata correttamente, funziona bene, se erroneamente otteniamo una situazione in cui durante un'audioconferenza aumenta il carico sul canale, inoltre in aggiunta a questo c'è il problema che l'immagine viene visualizzata male (nessuna immagine completa HD, un volto di 9–16 pixel). Un ulteriore ritardo molto forte si verifica quando si forma un loop tra il client, la workstation VDI, il server di videoconferenza e da lì il secondo VDI e il secondo client. È corretto connettersi direttamente dal client al server di videoconferenza, il che richiede l'installazione di un altro componente aggiuntivo.
Chiavi USB: non ci sono problemi con loro, smart card e simili, tutto funziona immediatamente. Possono sorgere difficoltà con lettori di codici a barre, stampanti per etichette, macchine (sì, esisteva una cosa del genere) e registratori di cassa. Ma tutto si sta risolvendo. Con sfumature e non senza sorprese, ma alla fine risolte.
Quando un utente guarda YouTube da una stazione VDI, questa è la situazione peggiore sia per il carico che per il canale. La maggior parte delle soluzioni offre il reindirizzamento video HTML5. Il file compresso viene trasferito al client, dove viene visualizzato. Oppure al client viene inviato un collegamento per la comunicazione diretta tra il browser e l'hosting video (questo è meno comune).
sicurezza
La sicurezza si verifica in genere nelle interfacce dei componenti e nei dispositivi client. Alle giunzioni di un ecosistema, in parole povere, tutto dovrebbe funzionare bene. In pratica questo avviene nel 90% dei casi, e qualcosa deve ancora essere portato a termine. Negli ultimi anni, un altro acquisto di Vmvara si è rivelato molto conveniente: hanno aggiunto MDM all'ecosistema per gestire i dispositivi all'interno dell'azienda. Le VM hanno recentemente acquisito interessanti bilanciatori di rete (ex Avi Networks), che consentono di chiudere la questione della distribuzione dei flussi, ad esempio un anno dopo il completamento di VDI. Un'altra caratteristica puramente proprietaria è la buona ottimizzazione delle filiali grazie ai loro nuovi acquisti quando hanno assunto la società VeloCloud, che produce SD-WAN per le reti delle filiali.
Dal punto di vista dell'utente finale, l'architettura e il fornitore sono quasi invisibili. Ciò che è importante a livello globale è che esista un client per qualsiasi dispositivo; puoi connetterti da un tablet, Mac o thin client Windows. C'erano clienti anche per i televisori, ma ora, per fortuna, non ci sono più.
La particolarità delle installazioni VDI ora è che l'utente finale semplicemente non ha un computer a casa. Spesso hai un tablet Android debole (a volte anche con mouse o tastiera), oppure potresti anche essere fortunato e avere un computer con Win XP. Che, come puoi immaginare, non viene aggiornato da un po'. E non verrà mai più aggiornato. Oppure macchine molto deboli, dove il client non è installato, le applicazioni non funzionano, l'utente non può lavorare. Fortunatamente, sono adatti anche dispositivi molto deboli (non sempre comodi, ma adatti), e questo è considerato un grande vantaggio di VDI. Ebbene, per quanto riguarda la sicurezza, è necessario testare la compromissione dei sistemi client. Questo accade abbastanza spesso.
Alla luce delle raccomandazioni di Rospotrebnadzor sull'organizzazione del lavoro delle imprese a rischio di COVID-19, connettersi ai propri luoghi di lavoro in ufficio è molto importante. Sembra che questa storia durerà a lungo e sì, se stavi pensando alla VDI, puoi iniziare a testare. Tornerà utile. Le raccomandazioni sono , chiarimenti . È importante sottolineare che la VDI può essere utilizzata anche per ammodernare gli spazi per soddisfare i requisiti di conformità. Il regolatore introduce alcuni standard di distanziamento. Ad esempio, in un ufficio di 50 mq. m non possono esserci più di cinque dipendenti.
Bene, se hai domande sulla VDI che non sono destinate ai commenti, ecco la mia email: [email protected].
Fonte: habr.com