Nonostante il lavoro che abbiamo svolto su VMware vSAN in termini di contenuti e recensioni sul sito, potrebbe sorprendere alcuni scoprire che non lo avevamo ancora utilizzato in produzione. Dopo aver aggiornato i nostri server di laboratorio (12 Dell EMC PowerEdge R740xd ), abbiamo deciso di risolvere questo problema riutilizzando alcuni server PowerEdge R730 e degli SSD aggiuntivi che avevamo a disposizione. Il risultato è una modesta configurazione di vSAN 6.6 che utilizzeremo per ospitare le VM necessarie per i test, oltre a fungere da piattaforma per testare e segnalare le nuove funzionalità di vSAN. Questa implementazione, tuttavia, solleva immediatamente una domanda che spesso incuriosisce chi acquista vSAN: come si migrano i carichi di lavoro esistenti su vSAN?
Come per la maggior parte delle aziende, il nostro storage di laboratorio primario è un mix di condivisioni iSCSI e storage Fibre Channel con la maggior parte dei nostri dati che risiedono su array Dot Hill e Fusion-io ION. Esistono diversi modi per affrontare questa migrazione, dallo spostamento di VM tra archivi dati con un comando SVMotion di base con lo spazio di archiviazione collegato localmente a un host che può vedere entrambi gli archivi dati o una migrazione in due passaggi in cui cambiano sia l'host che l'archivio dati.
Se disponi di un array di archiviazione con LUN iSCSI, questo processo è piuttosto semplice. Aggiungi il dispositivo di storage iSCSI a uno dei tuoi host vSAN se non lo hai già fatto, aggiungi la destinazione iSCSI dal tuo array di storage e accedi rapidamente a quella VM all'interno del cluster vSAN senza nemmeno dover migrare il datastore. Se disponi di un array di archiviazione che comunica tramite FC, puoi sfruttare un HBA FC se ne esiste già uno all'interno del server oppure aggiungerne uno all'host. Se lo storage FC non verrà utilizzato molto in futuro, i costi e i tempi di inattività associati all'installazione dell'HBA potrebbero non valerne la pena; in tal caso passeremo al processo in due fasi.
Quando sposti le VM tra host ESXi in cui il calcolo e lo storage cambieranno nello stesso movimento, puoi spostare la VM ovunque nel tuo ambiente purché i dispositivi possano comunicare tra loro all'interno del tuo vCenter. Questa è un'opzione che ha la massima compatibilità, ma potrebbe non essere il percorso di trasferimento più veloce se ne esiste già uno nativo. Per VM individuali o piccoli gruppi, questo potrebbe non essere un problema, ma con VM piuttosto grandi o batch di grandi dimensioni potrebbe essere garantito un percorso di trasferimento più rapido.
Nel nostro caso possiamo vedere che il trasferimento della VM ha richiesto solo pochi minuti, con il collegamento di rete 10G tra i due host che aiuta a spingere la velocità fino a circa 400 MB/s. Nel complesso, questo è uno dei passaggi più semplici associati alla messa in funzione della piattaforma vSAN, ma esistono alcuni modi per affrontarlo a seconda delle esigenze o delle capacità hardware.
In questo articolo abbiamo parlato a lungo della facilità di migrazione di VMDK VMware e condivisioni iSCSI esistenti a vSAN. In qualsiasi organizzazione già virtualizzata, questo processo è piuttosto semplice. VMware offre anche uno strumento per le migrazioni bare metal; in precedenza abbiamo utilizzato VMware vCenter Converter per virtualizzare i carichi di lavoro legacy. Indipendentemente dal metodo scelto, vSAN offre notevoli vantaggi in termini di efficienza operativa e risparmio sul costo totale di proprietà (TCO) rispetto alle implementazioni IT tradizionali. Siamo entusiasti di constatare questi benefici nel nostro laboratorio e non vediamo l'ora di pubblicare ulteriori contenuti basati su esperienze reali.
Amazon