No results found
Quando si valuta la migrazione presso un Cloud Provider di uno o più server appartenenti a un’infrastruttura fisica o virtuale presente presso la sede di un’azienda o presso un altro Cloud Provider, si pone il problema di affrontare la quantità di lavoro necessaria per effettuare la migrazione; tale problema viene percepito e talvolta è tale, come uno degli elementi che frenano il passaggio.
Reinstallare tutti i software e rifare le configurazioni è un incubo, oltre che essere un lavoro molto dispendioso in termini di tempo e quindi di costi per il cliente: ad esempio immaginare di dover rifare un Domain Controller è sicuramente l’aspetto più preoccupante di tutti, perché bisogna passare su tutti i client a rifare la join del dominio e tutto quanto ne consegue. Ma anche pensare di dover migrare un server gestionale può essere un’operazione poco pratica perché può coinvolgere altri fornitori, il che va ad aumentare il costo della migrazione.
CoreTech vi assiste nella migrazione sul proprio Cloud e in questo tutorial verrà spiegato come tale operazione sia fattibile senza troppe preoccupazioni, utilizzando il tool vCenter di VMware.
Prima di entrare nel dettaglio vediamo che cosa si può coinvolgere nella migrazione; ebbene, è possibile migrare servizi come la posta elettronica e i servizi di comunicazione, tra cui i prodotti Kerio (Kerio Connect, ad esempio) SmarterMail e i Centralini.
È poi possibile migrare software gestionali ed ERP come Business Central, Fatture in Cloud, Esatto, E, Zucchetti, oltre ai gestionali basati su Microsoft Navision.
Quanto ai server, è possibile migrarne una gran varietà e tra questi i tipi più diffusi come File Server, Print Server e DNS.
Invece non è possibile migrare su Cloud i Server dhcp e i Domain Controller. Inoltre Non è possibile migrare un Data Center acceso perché è in continuo aggiornamento ed è costantemente sincronizzato con i Personal Computer e client ad esso collegati.
Se si va a migrare un Data Center si verificherà la presenza di tutta una serie di informazioni non aggiornate che magari non nell’immediato, ma presto, daranno problemi con i client.
In questo caso esistono però dell’escamotage che permettono comunque di eseguire la migrazione e sincronizzare poi i dati in vari modi, perché abbiamo diverse strade da percorrere, di seguito elencate.
1. creare un nuovo server e farlo diventare DC e sincronizzarlo con quello da migrare;
2. fare il demote di quello da migrare passando i ruoli a quello in Cloud;
3. migrare la macchina virtuale diventata ora stand-alone;
4. una volta migrata farla tornare Data Center e rimigrare su questa i ruoli;
5. fare il demote del server Data Center creato in Cloud e poi eliminarlo.
Per quanto laborioso, quest’ultimo passaggio permette di aggirare il problema e di riuscire a migrare anche un Data Center.
In generale prima di migrare verso Stellar un server attivo, On Premises o ospitato presso un’altro cloud provider, è necessario valutare lo stato del sistema operativo installato in esso: se la versione del sistema operativo è datata, (ad esempio per Windows 2003 o Windows 2008) non è più supportata dal produttore e la migrazione potrebbe essere intesa come re-installazione di un nuovo server con un sistema operativo più recente come Windows 2016/2019.
Grazie ai tool forniti da VMware è possibile prendere una macchina fisica o virtuale e convertirla in una Virtual Machine presso il sistema Cloud CoreTech, facendola diventare un server STELLAR a tutti gli effetti.
Per fare la migrazione VMware rende disponibile un tool chiamato vCenter converter, che converte rapidamente le macchine fisiche remote e locali in macchine virtuali senza alcun downtime. La conversione simultanea consente implementazioni di virtualizzazione su larga scala, offre ampio supporto per macchine fisiche di origine, formati delle macchine virtuali VMware e Microsoft e alcuni formati di immagine di dischi di terze parti.
La console di gestione centralizzata che ci supporta consente di mettere in coda e monitorare più conversioni simultaneamente, in locale e in remoto, nella sede principale e nelle filiali.
VMware vCenter converter offre elevate prestazioni e affidabilità nella migrazione perché:
Il tool di VMware offre interoperabilità, perché vCenter Converter supporta molte macchine fisiche di origine, incluse le versioni Server e Desktop di Windows e Linux. In più supporta la conversione di macchine virtuali di terze parti come Hyper-V e KVM.
La gestione delle migrazioni si esegue mediante una console di gestione centralizzata che consente agli utenti di mettere in coda e monitorare più conversioni simultaneamente, anche in locale. Le semplici procedure guidate riducono al minimo il numero di operazioni per completare la conversione.
Il supporto della clonazione in remoto e locale consente di effettuare le conversioni anche in luoghi fisicamente più lontani come le filiali.
È possibile convertire macchine virtuali gestite da vCenter Server per l’utilizzo in altre soluzioni VMware, ovvero utilizzare vCenter Converter Standalone per eseguire vari tipi di attività di conversione.
Per effettuare la migrazione bisogna collegarsi alla macchina da migrare, installare in essa solo la parte AGENT di VMware vCenter (che richiede la porta 9089) conoscere l’indirizzo IP pubblico della macchina che si collegherà e poi servirà, per la gestione da console centralizzata, conoscere nome utente e password amministrativi per poter grabbare la macchina. Notare che VMware vConverter può essere installato indifferentemente su server fisici o virtuali.
Dunque, per prima cosa si scarica VMware vCenter Converter Standalone e si lancia l’installazione scegliendo l’opzione Client-Server installation (advanced); nel passaggio successivo, quando viene richiesto l’Agent Service Port si scrive nella relativa casella 9089, che è il numero della porta utilizzata dall’agente di migrazione per connettersi alla macchina (immagine seguente).
Notare che l’installazione Client-Server consente di selezionare i componenti del convertitore che si desidera installare sul sistema, che sono:
Quindi nella schermata successiva si sceglie Converter agent, che è l’unica voce non crocettata, e si clicca su Next (immagine seguente).
Vedete che con questo tipo di installazione è disponibile la sola opzione Converter agent.
Una volta completata l’installazione si può lanciare il programma vCenter Converter Standalone, accedendo così alla schermata principale (console di gestione) da cui occorre creare un job di conversione; l’approccio da adottare per la creazione del job dipende dal tipo di sorgente (la macchina da migrare) e di destinazione (nel nostro caso il Cloud).
Dunque, dalla schermata principale si deve cliccare sul pulsante Convert Machine il che aprirà la finestra di dialogo Conversion (immagine seguente) che prevede tante sezioni o step quanti sono i nomi indicati nel menu a sinistra, ossia Source System, Destination System, Destination Virtual machine, Destination Location, Options e Summary.
Inizialmente ci troveremo sulla prima sezione (Source System) dove per prima cosa dovremo inserire i dati della macchina da migrare. Tra questi il tipo di macchina (Select source type) scegliendolo nel menu cliccando sul pulsante d’opzione Powered on se dovremo migrare una macchina accesa o Powered off se la macchina sarà spenta (cioè inattiva).
Cliccando su View source details potete, se lo desiderate, vedere le informazioni hardware e software riguardanti la macchina sorgente.
Notate che prima di proseguire con la conversione occorre preparare la macchina Windows sorgente, se si opera una migrazione di una macchina accesa, in questo modo:
Fatto questo, una volta inseriti nella finestra anche l’IP address della macchina e le credenziali d’accesso possiamo cliccare su Next e passare alla sezione Destination System, dove definiremo i parametri del server Cloud di destinazione (immagine seguente) ossia il sistema di destinazione, oltre al tipo, che nel nostro caso sarà VMware Infrastructure virtual machine. Spuntiamo l’opzione Use proxy mode in basso nel riquadro VM Infrastructure server details.
Scelta la destinazione con il menu a tendina Select destination type, il riquadro sottostante chiede di inserire i parametri che di volta saranno quelli del tipo di infrastruttura.
Fatto questo, cliccando su Next andiamo alla sezione successiva della finestra Conversion (Destination Virtual Machine); in pratica qui ci troviamo nella sezione Destination Virtual Machine dove occorre specificare il nome della macchina virtuale di destinazione all’interno del sistema (Cloud) di destinazione.
Selezioniamo quindi il Data Center dove collocare la Virtual Machine destinazione e nella casella Name assegneremo un nome al server dove avverrà la migrazione: nell’immagine seguente è stato assegnato Server00.
Per impostazione predefinita, vCenter Converter Standalone propone il nome della macchina sorgente (origine) nella casella Name, ma possiamo cambiarlo a piacimento; chiaro che mantenerlo è la soluzione più immediata, in quanto la macchina in Cloud sarà riconosciuta come quella migrata.
Se il nome dovesse già essere esistente nella lista delle Virtual achine presenti nel Data Center o nella cartella selezionata andrà cambiato.
Fatta la scelta si clicca su Next e si accede alla sezione Destination Location, che permette la scelta del Cluster, host, Datastore o del Datastore (in base alla destinazione impostata in precedenza) di destinazione; qui, in pratica possiamo modificare l’ambiente destinazione per la VM creata, includendo host, resource pool o cluster dove collocare la macchina virtuale di destinazione, scegliendo il Data Store dove immagazzinare i file della VM di destinazione.
Nella sezione Destination Location sarà anche possibile scegliere la versione dell’hardware della macchina virtuale da creare nel Cloud: nel caso nostro caso (immagine seguente) impostiamo come Datastore CL6-MSA-STORE e come versione la Version 11.
Cliccando su Next passiamo alla sezione successiva, che è Options, nella quale comunicheremo all’agente le opzioni desiderate per la migrazione che il job dovrà gestire. Questo passaggio ci permette di personalizzare le risorse hardware assegnate alla macchina virtuale di destinazione, come ad esempio il numero di CPU, la quantità di RAM, ovvero le risorse della macchina virtuale che si sta per creare; è possibile assegnare e modificare risorse, aggiungere dischi, selezionare volumi e quant’altro.
L’immagine seguente propone la finestra riepilogativa delle opzioni.
I parametri impostabili in questa sezione sono quelli elencati nel riquadro centrale in grassetto e per impostarli si clicca sulla voce Edit in blu accanto a ciascuno.
Per esempio con Data to Copy si può impostare, dal menu a tendina Data copy type, il tipo di copia da effettuare, impostare i parametri del volume sorgente (dalla tab Source volumes) e creare il layout delle risorse di storage sulla macchina virtuale da creare (tab Destination layout).
Spuntando le apposite caselle d’opzione in basso è anche possibile ignorare il page file e l’hibernation file oltre che creare un layout di partizionatura ottimizzato per la migrazione da eseguire. L’immagine seguente riguarda proprio le impostazioni Data to copy.
Si può scegliere se copiare tutti i dischi o selezionare i volumi da copiare e quelli da escludere; per destinazioni con più datastore è possibile selezionare la data location in specifici nel nostro ambiente virtuale. Se la macchina sorgente ha più dischi e volumi è possibile impostare l’agente affinché avvii trasferimenti dati concorrenti.
Volendo, è possibile gestire lo spazio su disco nel destination datastore, modificando la dimensione assegnata ai volumi su disco prima di avviare la conversione: sempre dal menu a tendina Data copy type, si sceglie Select volumes to copy e nella colonna Destination size si sceglie l’opzione che permette di specificare la dimensione del destination volume. Qui ci sono quattro possibilità:
Per migliorare le performance dello spazio di storage nella migrazione di una macchina Windows potete modificare la dimensione del volume assegnato al cluster; questo cambia le modalità di clonazione da block level a file level. Allo scopo, sempre dalla voce di menu Data to copy si sceglie Volumes to copy, si clicca su Advanced e poi sulla tab Destination layout; poi si sceglie il volume dove cambiare la cluster size e nella colonna Cluster size si opta per “specify the cluster size” relativamente al volume di destinazione. Qui vengono proposte tre opzioni:
Select a predefined size, che permette di scegliere, tra un elenco di possibilità, una cluster size per il volume di destinazione.
Tornando al menu del riquadro centrale, cliccando su Advanced options si accede alla finestra mostrata nell’immagine seguente, che riguarda alcune impostazioni avanzate raggruppate in due tab: Synchronize e Post-conversion; nella prima potete impostare l’eventuale sincronizzazione dei dati scegliendo tra subito dopo la migrazione (Run immediately after cloning) e in un momento successivo (opzione Schedule) programmando data e ora di esecuzione, eventualmente eseguendo una sincronizzazione finale.
Sotto la casella Perform final synchronization sono elencate le condizioni in cui non è possibile tale sincronizzazione finale, come ad esempio se si cambiano le dimensioni del cluster, se la dimensione dei settori logici è diversa da 512 byte e se si è scelta la formattazione FAT e la macchina sorgente è basata su Windows Vista o successivo.
Apriamo una parentesi riguardo il dimensionamento delle risorse: se stiamo migrando un server on-premise in casa del cliente, fisico o virtualizzato, dobbiamo valutare di quali risorse disponeva e adeguare la scelta delle risorse Cloud; con la CPU si può partire dal minimo (magari 2 soli core) e aumentarla se necessario. Invece sulla RAM non c’è molta libertà, perché se il server origine usa 8GB (l’occupazione di verifica in Task Manager) tanti se ne dovranno allocare anche in Cloud; a riguardo ricordate che quando si migra un server fisico non va considerata la RAM installata ma quella impiegata dal sistema operativo e dagli applicativi.
Quanto allo spazio di storage va considerato che è possibile solo aumentarlo, a meno di non creare un nuovo disco e spostarvi tutti i dati, ma tale operazione è fattibile solo se il server ha dischi distinti per il sistema operativo e dati.
Torniamo ora alla configurazione del converter: quando abbiamo fatto tutte le impostazioni desiderate clicchiamo su Next per accedere alla finestra Summary, che ci permette di vedere le impostazioni del job di migrazione e se queste non sono da modificare, con un clic sul tasto Finish viene creato il job, il quale verrà inserito nella lista dei job esistenti nell’interfaccia utente del converter.
Per iniziare la creazione della macchina virtuale bisogna quindi selezionare il job d’interesse dalla lista e avviarlo. Durante la migrazione, la finestra di lavoro propone i dettagli sul progresso della migrazione e il tempo restante al suo completamento. È sempre possibile osservare il progresso e lo stato dei job e tasks impostati mediante le funzioni Task View e Job View dell’interfaccia utente di vCenter Converter Standalone.
A migrazione completata otterremo una schermata come quella riportata nell’immagine seguente, che riepiloga tutte le informazioni sull’operazione in un riquadro di log.
Notate che il converter può gestire e permette di creare più di un job di migrazione e di eseguire di volta in volta, richiamandolo dall’apposita lista, quello desiderato
Se durante l’esecuzione di un job o un task si verifica un problema che ne causi il fallimento, il file di log permette di capire cosa non ha funzionato. Per ogni job è possibile esportare il Log File e rivederlo per ottenere informazioni sui lavori o inviare una copia dei file di registro al supporto tecnico VMware.
Concludiamo rispondendo a una domanda che si pone chi deve valutare la migrazione di un server su Coud, ossia quanto tempo richiede la migrazione con il tool di VMware? Ebbene, dalle prove effettuate abbiamo riscontrato che mediamente per migrare una VM con storage da 140GB con una connettività Internet che supporta una velocità di 10 Mbps ci vogliono circa 8/10 ore, più un’ora per l’allineamento (sincronizzazione) tra la macchina origine e la destinazione, purché venga fatto subito dopo la migrazione (cioè impostando, in Opzioni, Synchronize con Synchronize changes e Run immediately after cloning).
Invece per una VM da 50GB ci vogliono dalle tre alle quattro ore, in base alla velocità della linea a disposizione.