Hai mai pensato a cosa fa uno scanner con una workstation VDI? All'inizio sembra tutto a posto: si collega come un normale dispositivo USB ed è "trasparente" per la macchina virtuale. Poi l'utente dà il comando per scansionare e tutto va a rotoli. Nel migliore dei casi, il driver dello scanner si blocca, nel peggiore, dopo un paio di minuti anche il software dello scanner, e potrebbe influenzare anche altri utenti del cluster. Perché? Perché per ottenere un'immagine compressa di cinque megabyte, è necessario inviare attraverso USB 2.0 dati di due o tre ordini di grandezza maggiori. La banda passante del bus è di 480 Mbit/s.
Quindi è fondamentale testare tre aspetti: UX, periferiche e sicurezza. C'è differenza nel modo di testare. Si possono installare agenti localmente su ogni workstation virtuale. Questo è relativamente economico, ma non mostra il carico sulla rete e non calcola in modo del tutto corretto il carico sulla CPU. La seconda opzione è implementare in un'altra posizione il numero necessario di robot emulatori e iniziare a connetterli ai posti di lavoro reali come veri utenti. Aggiungerà carico dal protocollo di trasmissione del flusso video dello schermo (più precisamente, dei pixel modificati), analisi e invio di pacchetti di rete, permetterà di comprendere i carichi sulla rete. La rete, in generale, viene raramente testata.
L'UX è la velocità di esecuzione delle varie azioni da parte dell'utente finale. Esistono pacchetti di test che mettono sotto stress l'installazione coinvolgendo centinaia di utenti e fanno le azioni tipiche per loro: avviano pacchetti per ufficio, leggono PDF, navigano, e raramente guardano contenuti per adulti durante l'orario di lavoro, e così via.
Un ottimo esempio di perché questi test siano importanti in anticipo si è visto nell'ultima installazione. Migliaia di utenti stanno migrando a VDI, con ufficio, browser e SAP. Il dipartimento IT dell'azienda è evoluto, quindi c'è una cultura del test di carico prima delle implementazioni. Dalla mia esperienza, di solito è necessario convincere il cliente a fare questo, perché i costi sono alti e i benefici non sempre chiari. Ci sono calcoli su cui si può sbagliare? In realtà, questi test rivelano problemi che si pensava di poter verificare, ma non si era fatto.
Installazione
Sei server, la configurazione è la seguente:
Non avevamo accesso allo storage del cliente, che veniva fornito come spazio come servizio, in effetti. Ma sappiamo che è completamente flash. Non sappiamo quale tipo di all-flash, ma le partizioni sono da 10 TB. VDI è VMware per scelta del cliente, poiché lo stack è già noto al team IT, e tutto si integra piuttosto bene in un'infrastruttura complessiva. VMware spesso 'cattura' le aziende nella sua ecosistema, ma se il budget d'acquisto è sufficiente — per anni non si conosceranno problemi. Ma questo è spesso un "grande se". Abbiamo uno sconto considerevole, e il cliente ne è a conoscenza.
Iniziamo i test, perché il team IT non lancia praticamente nulla in produzione senza test. VDI non è qualcosa che può essere avviato e poi accettato. Gli utenti vengono caricati gradualmente, e potrebbero sorgere problemi anche dopo sei mesi. Cosa che, ovviamente, a nessuno piace.
450 "utenti" nei test, il carico lo generiamo localmente. Gli utenti virtuali compiono diverse azioni contemporaneamente, misuriamo il tempo di ogni operazione nel corso di alcune ore di lavoro:
Osserviamo come si comporteranno i server, lo storage. Riuscirà VDI a creare il numero necessario di postazioni lavorative virtuali e così via. Poiché il cliente non ha scelto la strada della iperconvergenza, optando per uno storage flash, era necessario controllare anche la correttezza del dimensionamento.
Se qualcosa si blocca, è necessario modificare le impostazioni del farm VDI, in particolare la distribuzione delle risorse tra utenti di diverse categorie.
Periferica
Di solito ci sono tre situazioni con le periferiche:
- Il cliente semplicemente dice che non colleghiamo nulla (se non le cuffie, che di solito vengono riconosciute "out of the box"). Negli ultimi cinque anni, ho visto raramente cuffie che non si collegassero da sole e che non venissero riconosciute da VMware.
- Il secondo approccio consiste nel cambiare le periferiche nell'ambito del progetto di implementazione VDI: scegliamo quelle testate da noi e supportate dal cliente. Questo è un caso raro per motivi evidenti.
- Il terzo approccio consiste nel passare attraverso l'hardware esistente.
Già conoscete il problema con gli scanner: è necessario installare un software intermedio sul dispositivo di lavoro (thin client), che riceve il flusso USB, comprime l'immagine e la invia al VDI. Per una serie di motivi, questo non è sempre possibile: se sui client Win (computer domestici e thin client) tutto funziona bene, per le distribuzioni *nix di solito il fornitore del VDI supporta solo una certa distribuzione specifica e iniziano le complicazioni, così come per i client Mac. Nella mia esperienza, pochi hanno mai collegato stampanti locali da installazioni Linux in modo che funzionassero in fase di debug senza dover chiamare continuamente l'assistenza. Ma rispetto a un tempo, è già un passo avanti; anche solo per farle funzionare.
La videoconferenza è qualcosa che tutti i clienti vogliono, prima o poi, che funzioni bene. Se il cluster è progettato correttamente, tutto funziona bene; se è progettato male, ci troviamo in una situazione in cui durante una audioconferenza la carico sul canale aumenta, e, in aggiunta, si presenta il problema che l'immagine è di scarsa qualità (niente full HD, volti da 9–16 pixel). Si verifica un significativo ritardo quando si crea un anello tra il client, il workstation VDI, il server di videoconferenza, da cui si passa a un secondo VDI e a un secondo client. È opportuno connettersi direttamente dal client al server di videoconferenza, il che richiede l'installazione di un ulteriore componente.
Non ci sono problemi con le chiavi USB; le smart card e simili funzionano out-of-the-box. Le difficoltà sorgono con scanner di codici a barre, stampanti per etichette e macchinari (sì, è successo anche questo), registratori di cassa. Ma tutto può essere risolto. Ci sono delle sfide e qualche sorpresa, ma alla fine si riesce sempre a trovare una soluzione.
Quando un utente guarda YouTube da una stazione VDI, è la situazione peggiore sia per il carico che per il canale. La maggior parte delle soluzioni offre il redirect video in HTML5. Un file compresso viene inviato al client, dove viene riprodotto. Oppure al client viene fornito un link per una connessione diretta tra il browser e il servizio di video hosting (questo avviene meno frequentemente).
Sicurezza
La sicurezza di solito presenta punti critici nei collegamenti tra componenti e sui dispositivi client. Nei collegamenti all'interno di un'unica ecosistema, tutto dovrebbe funzionare bene in teoria. Nella pratica, ciò si verifica nel 90% dei casi, e ci sarà sempre qualcosa da migliorare. Negli ultimi anni, un'altra utile acquisizione da parte di VMware è stata l'integrazione di MDM per la gestione dei dispositivi all'interno dell'azienda. VMware ha recentemente introdotto affascinanti bilanciatori di rete (ex Avi Networks), che risolvono la questione della distribuzione del traffico anche un anno dopo la consegna del VDI, ad esempio. Un'altra caratteristica tipica di VMware è una buona ottimizzazione per le filiali, grazie all'acquisto recente della società VeloCloud, che crea SD-WAN per reti di filiali.
Dal punto di vista dell'utente finale, l'architettura e il fornitore sono quasi impercettibili. L'aspetto globale importante è che esiste un client per qualsiasi dispositivo: da un tablet, un Mac, un thin client Windows ci si può connettere. Ci sono stati anche client per televisori, ma ora, per fortuna, non ci sono più.
L'aspetto attuale delle installazioni VDI è che l'utente finale a casa spesso non ha un computer. Spesso ha solo un debole tablet Android (a volte anche con mouse o tastiera), oppure può anche capitare di avere un computer vecchio con Windows XP. Come potete immaginare, questo non è stato aggiornato da tempo. E non verrà mai aggiornato. O si trovano macchine molto deboli, dove il client non può essere installato, le applicazioni non funzionano e l'utente non può lavorare. Per fortuna, anche dispositivi molto deboli sono compatibili (non sempre in modo comodo, ma funzionali), e questo è considerato un grande vantaggio del VDI. Quanto alla sicurezza, è necessario testare la compromissione dei sistemi client. Questo accade abbastanza spesso.
Alla luce delle raccomandazioni dell'agenzia sanitaria russa per l'organizzazione del lavoro nelle aziende 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 avete pensato al VDI, potete iniziare a testarlo. Sarà utile. Le raccomandazioni sono disponibili, chiarimenti. , chiarimenti . È importante che con l'ausilio del VDI sia possibile anche ristrutturare gli spazi per rispettare i requisiti. Il regolatore sta introducendo determinate norme di distanziamento. Ad esempio, in un ufficio di 50 mq non possono esserci più di cinque dipendenti.
Se avete domande sul VDI che non siano per commenti, ecco la mia email: SSkryl@croc.ru.
Fonte: habr.com
