{"id":87005,"date":"2020-07-02T07:42:17","date_gmt":"2020-07-02T05:42:17","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/podvodnye-kamni-pri-perehode-na-vdi-chto-testirovat-zaranee-chtoby-ne-bylo-muchitelno-bolno"},"modified":"2020-07-02T07:42:17","modified_gmt":"2020-07-02T05:42:17","slug":"podvodnye-kamni-pri-perehode-na-vdi-chto-testirovat-zaranee-chtoby-ne-bylo-muchitelno-bolno","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/podvodnye-kamni-pri-perehode-na-vdi-chto-testirovat-zaranee-chtoby-ne-bylo-muchitelno-bolno","title":{"rendered":"I problemi durante la transizione a VDI: cosa testare in anticipo per evitare dolori inutili","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"I
\nHai 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 \u00e8 \"trasparente\" per la macchina virtuale. Poi l'utente d\u00e0 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\u00e9? Perch\u00e9 per ottenere un'immagine compressa di cinque megabyte, \u00e8 necessario inviare attraverso USB 2.0 dati di due o tre ordini di grandezza maggiori. La banda passante del bus \u00e8 di 480 Mbit\/s. <\/p>\n

Quindi \u00e8 fondamentale testare tre aspetti: UX, periferiche e sicurezza. C'\u00e8 differenza nel modo di testare. Si possono installare agenti localmente su ogni workstation virtuale. Questo \u00e8 relativamente economico, ma non mostra il carico sulla rete e non calcola in modo del tutto corretto il carico sulla CPU. La seconda opzione \u00e8 implementare in un'altra posizione il numero necessario di robot emulatori e iniziare a connetterli ai posti di lavoro reali come veri utenti. Aggiunger\u00e0 carico dal protocollo di trasmissione del flusso video dello schermo (pi\u00f9 precisamente, dei pixel modificati), analisi e invio di pacchetti di rete, permetter\u00e0 di comprendere i carichi sulla rete. La rete, in generale, viene raramente testata.
\n<\/a><\/noindex>
\nL'UX \u00e8 la velocit\u00e0 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\u00ec via. <\/p>\n

Un ottimo esempio di perch\u00e9 questi test siano importanti in anticipo si \u00e8 visto nell'ultima installazione. Migliaia di utenti stanno migrando a VDI, con ufficio, browser e SAP. Il dipartimento IT dell'azienda \u00e8 evoluto, quindi c'\u00e8 una cultura del test di carico prima delle implementazioni. Dalla mia esperienza, di solito \u00e8 necessario convincere il cliente a fare questo, perch\u00e9 i costi sono alti e i benefici non sempre chiari. Ci sono calcoli su cui si pu\u00f2 sbagliare? In realt\u00e0, questi test rivelano problemi che si pensava di poter verificare, ma non si era fatto.<\/p>\n

Installazione<\/h3>\n

\nSei server, la configurazione \u00e8 la seguente:<\/p>\n

\"I
\n
\nNon avevamo accesso allo storage del cliente, che veniva fornito come spazio come servizio, in effetti. Ma sappiamo che \u00e8 completamente flash. Non sappiamo quale tipo di all-flash, ma le partizioni sono da 10 TB. VDI \u00e8 VMware per scelta del cliente, poich\u00e9 lo stack \u00e8 gi\u00e0 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 \u00e8 sufficiente \u2014 per anni non si conosceranno problemi. Ma questo \u00e8 spesso un \"grande se\". Abbiamo uno sconto considerevole, e il cliente ne \u00e8 a conoscenza. <\/p>\n

Iniziamo i test, perch\u00e9 il team IT non lancia praticamente nulla in produzione senza test. VDI non \u00e8 qualcosa che pu\u00f2 essere avviato e poi accettato. Gli utenti vengono caricati gradualmente, e potrebbero sorgere problemi anche dopo sei mesi. Cosa che, ovviamente, a nessuno piace. <\/p>\n

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:<\/p>\n

\"I
\n
\n\"I
\n
\n\"I
\n
\nOsserviamo come si comporteranno i server, lo storage. Riuscir\u00e0 VDI a creare il numero necessario di postazioni lavorative virtuali e cos\u00ec via. Poich\u00e9 il cliente non ha scelto la strada della iperconvergenza, optando per uno storage flash, era necessario controllare anche la correttezza del dimensionamento. <\/p>\n

\"I
\n
\n\"I
\n
\n\"I
\n
\n\"I
\n
\n\"I
\n
\n\"I
\n
\nSe qualcosa si blocca, \u00e8 necessario modificare le impostazioni del farm VDI, in particolare la distribuzione delle risorse tra utenti di diverse categorie. <\/p>\n

Periferica<\/h3>\n

\nDi solito ci sono tre situazioni con le periferiche:<\/p>\n