Vi siete mai chiesti cosa faccia uno scanner con una stazione VDI? All'inizio tutto sembra andare bene: viene rilevato come un dispositivo USB normale e è "trasparente" dalla macchina virtuale. Poi l'utente dà il comando per la scansione e tutto va a rotoli. Nel migliore dei casi, il driver dello scanner, nel peggiore — dopo un paio di minuti il software dello scanner, e questo può anche influenzare altri utenti del cluster. Perché? Perché per ottenere un'immagine compressa di cinque megabyte, è necessario inviare attraverso USB 2.0 due o tre ordini di grandezza di dati in più. La larghezza di banda del bus è di 480 Mbit/s.
Quindi è necessario testare tre cose: UX, periferiche e sicurezza — senza eccezioni. C'è una differenza nel modo in cui si testano. È possibile installare agenti localmente, su ogni stazione di lavoro virtuale. Questo è relativamente economico, ma non mostra carico sulla connessione e non calcola correttamente il carico sulla CPU. La seconda opzione è implementare in un altro posto il numero necessario di robot emulativi e iniziare a collegarli ai veri posti di lavoro come se fossero utenti reali. Ci sarà un aggravio dal protocollo di trasmissione del flusso video dello schermo (più precisamente, dei pixel modificati), l'analisi e l'invio dei pacchetti di rete renderanno evidenti i carichi sul canale. Il canale, in effetti, viene molto raramente controllato.
L'UX è la velocità di esecuzione di diverse azioni da parte dell'utente finale. Ci sono pacchetti di test che caricano l'installazione con centinaia di utenti e fanno azioni tipiche per loro: avviano pacchetti di ufficio, leggono PDF, navigano, raramente guardano pornografia durante l'orario di lavoro e così via.
Un buon esempio di perché tali test siano importanti in anticipo è stato nell'ultima installazione. Qui mille utenti migrano verso VDI, hanno office, browser e SAP. Il dipartimento IT dell'azienda è ben sviluppato, quindi c'è una cultura del test di carico prima delle implementazioni. Dalla mia esperienza, di solito è necessario convincere il cliente a farlo, perché i costi sono elevati e i benefici non sono sempre evidenti. Ci sono calcoli in cui si può sbagliare? In pratica, tali test rivelano posti in cui si pensava di sapere, ma non si poteva verificare.
Installazione
Sei server, la configurazione è la seguente:
Non avevamo accesso allo storage del cliente, che veniva fornito come un servizio, di fatto. Ma sappiamo che è tutto flash. Non sappiamo che tipo di all-flash, ma ci sono sezioni da 10 TB. VDI - VMware a scelta del cliente, poiché il team IT è già familiare con il stack e tutto si integra in modo abbastanza organico in un'infrastruttura completa. VMware tende a «dipendere» dalla sua ecosistema, ma se il budget è sufficiente per l'acquisto, si possono non avere problemi per anni. Ma questo è spesso un grande «se». Abbiamo uno sconto significativo, e il cliente lo sa.
Iniziamo i test, perché il team IT non porta quasi mai in produzione nulla senza test. VDI non è qualcosa che si può lanciare e poi accettare. Gli utenti vengono caricati gradualmente e si possono incontrare problemi dopo sei mesi. Cosa che, naturalmente, a nessuno piace.
450 «utenti» nel test, generiamo carico localmente. I robouser fanno diverse azioni contemporaneamente, misuriamo il tempo di ciascuna operazione per diverse ore di lavoro:
Osserviamo come si comporteranno i server e lo storage. Sarà in grado il VDI di creare il numero necessario di postazioni di lavoro virtuali e così via. Dato che il cliente non ha seguito la strada dell'iperconvergenza, ma ha optato per uno storage flash, era necessario verificare anche la correttezza del sizing.
Di fatto, se qualcosa rallenta, è necessario modificare le impostazioni della farm VDI, in particolare la distribuzione delle risorse tra gli utenti di diverse categorie.
Periferica
Ci sono solitamente tre situazioni con la periferica:
- Il cliente semplicemente dice che non colleghiamo nulla (tranne le cuffie, di solito visibili «out of the box»). Negli ultimi circa cinque anni vedo molto raramente cuffie che non si collegano da sole, e che non sono state riconosciute da VMware.
- Il secondo approccio prevede di cambiare la periferica nell'ambito del progetto di implementazione del VDI: prendiamo ciò che è stato testato da noi e supportato dal cliente. Un caso, per ovvi motivi, raro.
- Il terzo approccio è di utilizzare l'hardware esistente.
Già conoscete il problema con gli scanner: è necessario installare un software intermedio sulla workstation (thin client) che riceve il flusso USB, comprime l'immagine e la invia al VDI. A causa di alcune peculiarità, ciò non è sempre possibile: se sui client Windows (computer domestici e thin client) tutto funziona bene, per le distribuzioni *nix solitamente il fornitore del VDI supporta una specifica distribuzione e cominciano le danze con i tamburi, come anche sui client Mac. Nella mia esperienza, pochi sono riusciti a collegare stampanti locali da installazioni Linux in modo tale che durante la fase di debug funzionassero senza chiamate costanti al supporto. Ma va già meglio, qualche tempo fa - anche solo per farle funzionare.
La videoconferenza - tutti i clienti prima o poi vogliono che funzioni e funzioni bene. Se il server è progettato correttamente, funziona bene; se progettato male, ci troviamo in una situazione in cui durante la conferenza audio aumenta il carico sulla rete e, inoltre, emerge il problema che l'immagine è visualizzata male (full HD non c'è, il volto è composto da 9-16 pixel). Si verifica un ritardo molto forte quando c'è un loop tra il client, la workstation VDI, il server VKS, e da lì il secondo VDI e il secondo client. È corretto collegarsi direttamente dal client al server VKS, il che richiede l'installazione di un ulteriore componente.
Le chiavette USB - non ci sono problemi con esse, le smart card e simili funzionano subito. Le difficoltà si presentano con scanner di codici a barre, stampanti per etichette, macchine (sì, è successo anche questo) e casse. Ma tutto si risolve. Con delle sfide e qualche sorpresa, ma alla fine si risolve.
Quando un utente guarda YouTube da una stazione VDI, è la situazione peggiore sia per il carico che per la rete. La maggior parte delle soluzioni offre il reindirizzamento video HTML5. Il file compresso viene inviato al client, dove viene visualizzato. In alternativa, al client viene fornito un link per una connessione diretta tra il browser e il sito di hosting video (questo è più raro).
Sicurezza
La sicurezza di solito scintilla nei punti di giunzione dei componenti e sui dispositivi client. In teoria, nei punti di giunzione di un ecosistema tutto dovrebbe funzionare bene. In pratica, ciò avviene nel 90% dei casi, e c'è sempre qualcosa da sistemare. Negli ultimi anni, un'altra acquisizione di VMware si è rivelata molto utile: hanno integrato un ecosistema MDM per la gestione dei dispositivi all'interno dell'azienda. Di recente, VMware ha introdotto interessanti bilanciatori di carico di rete (ex Avi Networks), che consentono di affrontare il problema della distribuzione del traffico dopo un anno dalla consegna del VDI, ad esempio. Un'altra caratteristica puramente VMware è la buona ottimizzazione delle filiali grazie al loro recente shopping, quando hanno acquisito l'azienda VeloCloud, che produce SD-WAN per le reti filiali.
Dal punto di vista dell'utente finale, l'architettura e il fornitore sono quasi invisibili. Ciò che conta a livello globale è che esiste un client per ogni dispositivo, è possibile connettersi da un tablet, un Mac o un thin client Windows. C'erano anche client per i televisori, ma ora, per fortuna, non ci sono più.
La particolarità delle installazioni VDI attualmente è che l'utente finale a casa semplicemente non ha un computer. Spesso c'è un debole tablet Android (a volte anche con mouse o tastiera), oppure può capitare di avere persino un computer con Win XP. Che, come potete immaginare, non è stato aggiornato da un po' di tempo. E non verrà mai aggiornato. Oppure si tratta di macchine molto deboli, dove il client non si installa, le applicazioni non funzionano e l'utente non può lavorare. Fortunatamente, anche dispositivi molto deboli sono adatti (non sempre comodamente, ma adatti), e questo è considerato un grande vantaggio del VDI. Per quanto riguarda la sicurezza, è importante testare la compromissione dei sistemi client. Questo accade abbastanza di frequente.
In considerazione delle raccomandazioni dell'Rospotrebnadzor per l'organizzazione del lavoro delle imprese in condizioni di rischio COVID-19, la connessione ai propri posti di lavoro in ufficio è molto attuale. Sembra che questa situazione durerà a lungo, e sì, se stavi pensando al VDI, è il momento di iniziare a testarlo. Sarà utile. Le raccomandazioni sono disponibili , chiarimenti . È importante che con l'aiuto del VDI si possano anche riattrezzare gli spazi per rispettare i requisiti. Il regolatore introduce alcune norme di distanziamento. Ad esempio, in un ufficio di 50 mq non possono esserci più di cinque dipendenti.
Se hai domande su VDI non per commenti, ecco la mia email: SSkryl@croc.ru.
Fonte: habr.com
