Nessun risultato trovato
La gestione di server virtualizzati su Cloud Computing implica tutta una serie di attività che vanno dalla sicurezza all’ottimizzazione delle risorse, fino all’interfacciamento con la rete, alla migrazione dall’infrastruttura fisica, alla configurazione del firewall, del backup e via di seguito.
In questo tutorial verranno affrontate le problematiche connesse alla gestione di server in Cloud con particolare riferimento al Cloud Coretech e alle sue prerogative che lo distinguono dalla media delle offerte Cloud esistenti sul mercato.
Un tema fondamentale della gestione dei server su Cloud è quello della sicurezza, che deve partire dall’infrastruttura su cui i server vengono ospitati; per sicurezza si intende, in questo caso, la certezza che l’infrastruttura funzionie quindi la disponibilità e continuità del servizio (availability), per garantire la quale bisogna prediligere un ambiente clusterizzato. Andare su una VPS significa che se si rompe qualcosa, è vero che ci sono macchine stand-alone ma non sono in cluster, pertanto se si verifica un guasto, per quanto la cosa vada in carico al gestore del Cloud, un fermo dei server c’è. Purtroppo se si guasta un disco, un banco di RAM o qualcosa per cui la macchina virtuale va fermata, in quel momento non c’è la disponibilità (availability).
L’ideale è avere un’infrastruttura che offra un hardware che permetta, nel caso di qualsivoglia guasto dell’hypervisor, che la macchina virtuale del cliente sia fatta ripartire in tempi relativamente brevi su un altro nodo di un cluster e su un altro hypervisor. Quindi un’infrastruttura Cloud basata su cluster e non su singole macchine.
Un altro aspetto rilevante è la parte di rete e quindi il networking: qui si vanno a segregare le macchine virtuali in VLAN e se le macchine che fanno parte dello stesso cliente si devono vedere tra di loro; ad esempio nel caso di un Domain Controller dove poi c'è un gestionale, c'è un server SQL, l’RDP che devono dialogare fra loro per l’accesso degli utenti tramite Active Directory. Queste macchine ha senso che siano tutte all’interno della stessa VLAN.
Quando si deve creare un server in Cloud, alcuni provider permettono di scegliere come debba essere gestito a livello di rete, cioè se deve avere l’IP pubblico direttamente assegnato alla VM (quindi la macchina virtuale viene gestita dal firewall locale della macchina, ossia il firewall Windows o il firewall Linux e comunque quello del sistema operativo), piuttosto che avere un firewall condiviso e quindi avere poi l’IP privato sui server (sulle schede di rete). In definitiva è possibile scegliere se avere un firewall condiviso da gestire oppure avere un firewall dedicato.
Con riferimento allo schema proposto nell’immagine seguente, all’interno del Data Center che ospiterà l’infrastruttura e quindi i server Cloud, c’è generalmente un firewall di front-end, vale a dire quello che gestisce la connessione con Internet e che quindi è un firewall condiviso infrastrutturale; poi ci sono delle VM che possono essere in un contesto cluster oppure in configurazione server stand-alone.
Queste macchine possono avere un IP pubblico direttamente assegnato alla VM (il firewall in questo caso funziona come un router che instrada la connessione da e verso la VM) oppure la macchina virtuale può essere messa dietro un ulteriore firewall (di back-end) che le assegna un IP privato.
Quindi nel primo caso, ossia con l’IP pubblico direttamente sulla VM, arriva tutto su quest’ultima e poi bisogna avere il firewall della VM che gestisca le porte e quindo lo deve gestire il cliente a livello di sistema operativo, con tutte le limitazioni che ne possono derivare, perché comunque non è un firewall vero e proprio che fa quel lavoro. Avere il firewall condiviso impone delle limitazioni, innanzitutto sul numero di regole che possiamo creare e poi non si possono fare delle VLAN e poi non si ha accesso ai log del firewall.
Invece con un firewall dedicato, oltre avere una gestione diretta del networking si può ad esempio attivare delle VLAN perché ognuna può fare capo ad un IP privato.
Tecnicamente parlando, un firewall dedicato non è altro che un server Cloud con un’istanza virtuale della soluzione scelta, che nel caso del Cloud Coretech è il firewall Kerio Control.
Esiste anche un terzo caso dove ci si può creare una VM che fa da firewall che ha gli IP pubblici assegnati direttamente, quindi un firewall che il cliente può gestire completamente, dietro al quale si possono mettere tutte le VM che si desidera (schema dell’immagine seguente).
Avendo a disposizione un firewall dedicato virtuale è possibile poi creare delle VLAN personalizzate, a differenza del secondo caso dove le VLAN vengono assegnate, almeno per quanto riguarda il Cloud Coretech, automaticamente dal sistema di provisioning dei server; in realtà anche quelle dietro al firewall dedicato vengono assegnate automaticamente, però il sistema indica quali sono le WLAN e le classi di IP address da utilizzare, poi il cliente è libero di gestirle come preferisce. Si può anche creare una VLAN di VMZ, quindi col database a parte dove c'è un web server che comunica con Internet e poi c’è il database e si può far dialogare tramite regole del firewall il web server col database.
Il discorso sulle VLAN è importante perché nel momento in cui si inizia a lavorare in un contesto Cloud, la sicurezza è uno dei fattori più importanti rispetto alle situazioni on premise, dove si opera in un perimetro ristretto e nel quale le macchine non potranno mai comunicare con le altre.
Invece in Cloud, teoricamente tutte le macchine possono essere affacciate alla stessa VLAN, quindi potete mettere la stessa sulla stessa VLAN macchine di clienti diversi.
E questo è sconsigliabile, perché conviene mettere macchine di clienti diversi su VLAN differenti; in verità è possibile anche separare su VLAN differenti anche macchine dello stesso cliente. Ad esempio se è necessario comunicare attraverso la porta 25 di un Mail Server per mandare delle e-mail non è il caso di mettere la macchina sulla stessa VLAN di un’altra, perché tanto la porta 25 si può gestire attraverso regole.
Per esempio se nello stesso Cloud e quindi nella medesima infrastruttura è stato messo il Domain Controller del cliente, il gestionale, il web server e il Mail Server, quest’ultimo deve essere accessibile dall’esterno e viene quindi pubblicato su Internet, mentre il Domain Controller non deve essere affacciato su internet, ma deve essere accessibile solo dalla rete del cliente, quindi magari tramite una VPN. Però se lo si mette nella stessa VLAN del Mail Server, se qualcuno “buca” il server di posta può arrivare al Domain Controller e a quel punto è dentro la VLAN che comunica con la VPN e arriva a fare ciò che vuole, cioè attraverso la VPN può arrivare ai client nella sede del cliente proprietario dell’infrastruttura.
Per comprendere meglio il concetto si può spiegare che tipo di movimento si può verificare all’interno di un’infrastruttura Cloud: quello appena esposto si chiama movimento orizzontale o movimento est-ovest, ossia se nell’infrastruttura vi sono tre VM affacciate a un’unica VLAN dietro un firewall (dedicato o condiviso è irrilevante) e ognuna con un proprio IP privato, se un hacker riesce a passare il firewall e ad entrare nel Mail Server può fare quello che viene chiamato movimento orizzontale, quindi si può muovere da una macchina all’altra attraverso la VLAN. A quel punto l’hacker può compiere il movimento verticale, ossia nord-sud, come quello con cui da Internet è entrato nei livelli sottostanti e può accedere ai dati del database, del gestionale ecc.
L’immagine seguente chiarisce questi due possibili movimenti.
Quindi l’ideale è, se possibile, avere le macchine su VLAN distinte, oppure (ed è quello si stiamo implementando come Coretech) anche se le macchine sono in una rete privata, su una VLAN, si proteggono mediante il firewall di Windows, di Linux ecc. andando a restringere tutti gli accessi il più possibile a una certa macchina, lasciando aperti solo gli accessi che servono e in certi casi blindando un tipo di accesso a un IP specifico.
Per esempio se alla porta 1433 (la porta di MSSQL Server) deve accedere solo il gestionale si può creare una regola secondo la quale solo l’IP privato di esso possa accedere alla 1433; questa regola può essere creata nel firewall della macchina Windows.
Questo permette di chiudere gli accessi indesiderati alla macchina anche se si trova nella stessa VLAN di altri server, che si vedono, si pingano eccetera, però di fatto in quella che ospita il database può entrare solo il gestionale.
Per proteggere ulteriormente la macchina che ospita il database, se
non serve il remote desktop lo si va disabilitare; idem per le VMI, che se non servono per questioni di monitoring eccetera si disabilitano. Se invece servono, si scrive una regola come spiegato per la porta di MSSQL, ossia si va a mettere l’IP dal quale arriva la richiesta (mediante regola) che può essere un IP pubblico e il file sharing.
Questi accorgimenti servono perché statisticamente gli attacchi più consistenti sono stati quelli riguardanti il protocollo RDP (Remote Desktop Protocol) non aggiornato e il protocollo Microsoft di condivisione 445139. Per quanto riguarda l’RDP, se sorge l’esigenza si utilizzare il Desktop Remoto, se possibile restringiamo gli accessi quindi usiamo il firewall di front-end piuttosto che anche il firewall della VM stessa e adottiamo un software di autenticazione multi-fattore.
Attenzione che la protezione deve essere attivata su tutte le VM tramite i firewall dei sistemi operativi corrispondenti e non solo a livello di firewall di front-end, perché un attaccante che ha varcato la soglia dell’infrastruttura può utilizzare falle nell’RDP per passare da una macchina virtuale all’altra all’interno della VLAN.
Una VPN collegata tra due sedi di un’azienda che in qualche modo unisce l’ufficio di un’azienda di un cliente con quello del provider con i dipartimenti IT e poi ha visibilità completa di tutte le macchine è facile che qualcuno col PC si prenda un virus (magari un Trojan) che rimane silente per un certo periodo finché non riesce ad agire, quindi è inutile progettare un’infrastruttura su Cloud ultra-sicura se poi arriva un attacco dall’esterno perché la VPN è stata configurata con accesso illimitato, si va a creare una back door potenzialmente pericolosissima.
Quindi non è solo il Cloud che deve essere sicuro, ma anche quel pezzo di infrastruttura che unisce l’ufficio del cliente al Cloud deve essere messo in sicurezza.
Abbiamo parlato delle VLAN e del firewall condiviso e di quello dedicato dove si può fare tutto, abbiamo detto qualcosa
sulle VPN vi sono due scelte: site-to-site o client. Nel momento in cui facciamo le VPN, che siano site-to-site o client, ciò che arriva da questo tunnel VPN è assoggettato a delle regole sul firewall, quindi si definisce quale protocollo è abilitato ad accedere al Cloud
Non è possibile assegnare in una VPN degli IP blindati sul MAC address, però se si sta lavorando con una VPN client (poi dipende dal firewall) alla login dell'utente all’utente verrà sempre assegnato un determinato IP. In caso di DHCP del cliente si può correlare l’IP al MAC address e poi quando si crea l’utente, sul firewall per l’accesso in VPN si assegna l’IP.
Un altro aspetto fondamentale della sicurezza sono i backup e le rispettive politiche. Il Cloud Coretech fornisce due tipologie di backup: il backup completo di tutta la VM eseguito una volta al mese su storage separato e poi l’agente di 1Backup per eseguire il backup quando si desidera.
Ogni offerta di server Cloud Coretech include gli strumenti per gestire il backup dei dati, quindi se si acquista un server con un certo ammontare di storage, altrettanto ne ne ha disponibile nella sezione dedicata al backup, quindi se un cliente acquista uno storage da 40 GB associato alla VM, gliene viene assegnato altrettanto dove verrà depositato il backup della VM completa. Viene inoltre fornito, oltre allo spazio di backup, l’agente per gestire backup (nello specifico è 1Backup), quindi con il Cloud Coretech si dispone di tutti gli strumenti per la gestione dei backup e non solo lo storage dove mettere i backup.
In più viene fatto mensilmente e in maniera automatica un backup di tutta la macchina virtuale del cliente, oltre a quello dei dati compreso nell’offerta.
Inoltre è compresa la possibilità di gestire gli snapshot attraverso la gestione centralizzata dei server che si realizza tramite la piattaforma Sygma; quest’ultima mette a disposizione una serie di funzionalità tra cui la la gestione degli snapshot ed è molto utile soprattutto nel momento in cui bisogna svolgere delle attività particolarmente critiche sulle macchine, per cui in autonomia è possibile lanciare uno snapshot della macchina, fare l’attività che si desidera e solo se vengono fuori dei problemi a seguito dell’attività stessa.
Tutto questo perché quando si pensa di andare in Cloud ci deve essere una chiara strategia di backup, a prescindere dal fatto che si utilizzi una propria soluzione o quelle comprese nell’offerta Cloud Coretech; e bisogna fare attenzione al fatto che lo snapshot non è un backup, quindi il disporre di snapshot eseguiti ciclicamente non è come avere un backup, anche solo perché la continua creazione di shanpshot (che sono poi delle istantanee del sistema) rallenta la VM.
Andando alla struttura del cluster del Cloud Coretech, ci sono tre hypervisor e poi c’è l’unità di storage con tutti i dischi (immagine seguente); le VM risiedono, per quanto riguarda i file, sullo storage del cluster. Poi esiste uno storage a parte dove c’è il backup mensile delle VM che ha una certa retention. È possibile acquistare un pacchetto che permette di impostare retention maggiori e una frequenza personalizzata dei backup; ricordiamo che frequenza e retention sono due cose diverse: la prima significa ogni quanto si esegue un backup e la seconda per quanto vengono conservati i singoli backup. Va da sé che se la retention è troppo più grande della frequenza (periodicità) dei backup occorrerà prendere un ulteriore storage in quanto altrimenti prima o poi quello predefinito si esaurirà.
Chiaro che siccome il backup è un file compresso, lo spazio richiesto è minore di quello dei dati originari (quanto, dipende da che dati sono); ad esempio il backup di un database mySQL da 10 GB, il suo backup richiederà intorno ad 1,5 GB.
Oltre allo storage di backup VM, come mostra l’immagine precedente ne esiste uno dove finiscono i dati di 1Backup e quindi il backup dei dati del cliente, quindi file vari, posta elettronica, file di configurazione, database ecc.
Inoltre il Cloud Coretech fornisce compreso nell’offerta una replica del server in un altro Data Center. Quindi se un cliente acquista una macchina virtuale da 40 GB, non gli si alloca questo spazio ma tre volte tanto: 40 gigabyte per lo storage, 40 gigabyte per il backup e altrettanti per la replica. Gli snapshot risiededono sullo stesso disco, perché fanno parte della VM.
In autonomia è possibile eseguire un Reverse Snapshot e tornare alla configurazione iniziale della VM.
Va comunque precisato che difficilmente occorre eseguire backup aggiuntivi rispetto a quelli previsti dall’offerta, in quanto avere il backup di tutta la VM tutti i giorni non ha molto senso se viene già fatto il backup dei dati; può essere utile, ad esempio, se sono stati effettuati aggiornamenti
di Windows, ma in quel caso si copre l’esigenza con gli snapshot.
La scalabilità è abbastanza importante, nel senso che l’ideale per il cliente è poter scalare le risorse come si desidera, aggiungendo un core in più, solo della RAM in più, dello storage in più ecc.
Una particolarità del Cloud Coretech è che le risorse (CPU, RAM, storage) sono scalabili in maniera lineare, quindi per incrementare le CPU, lo storage e via di seguito è possibile acquistare unità di quello che occorre, senza essere costretti a passare a un’offerta superiore perché per avere una risorsa in più bisogna comperarne altre che non servono.
Questo è un elemento distintivo perché la gran parte dei Cloud Ptovider non permette la scalabilità lineare delle risorse ma vende pacchetti comprendenti un certo numero di CPU, di spazio di storage e di RAM, quindi chi vuole aumentare anche solo una di tali risorse deve comperare il pacchetto che ha l’ammontare richiesto, anche se non gli occorrono gli altri elementi.
Quindi la media delle offerte Cloud è a gradini, mentre nel Cloud Coretech ogni risorsa può essere aumentata o ridotta indipendentemente dalle altre e ciò può essere fatto anche in maniera istantanea, perché è possibile sottoscrivere nuove risorse direttamente dalla piattaforma Sygma ed averle immediatamente disponibili sulla macchina desiderata.
Coretech è un’azienda che si rivolge esclusivamente ai partner, quindi non vende direttamente ai clienti finali ma ai Service Provider; questo è una garanzia per i rivenditori perché non entreranno mai in concorrenza con Coretech e quindi con il loro Cloud Provider, cosa che invece succede con i Big Tech, che da tempo consentono all’utente finale di acquistare direttamente bypassando il tradizionale rivenditore.
In quest’ottica si colloca il fatto che le soluzioni offerte da Coretech ai rivenditori possono essere fornite con la formula White Label, nel senso possono essere brandizzate direttamente o tramite un’interfaccia di gestione; questo significa che il rivenditore può offrirle alla propria clientela con un proprio marchio e questo è un vantaggio a livello di immagine, per dare visibilità verso i clienti cui si sta erogando un servizio.
A parte la rigidità delle offerte, su molti Cloud quando si passa a un’offerta (pacchetto) differente non è possibile mantenere il proprio server e aggiungergli quanto previsto, ma per questioni legate all’architettura di tali Cloud bisogna reinstallare tutto e rifare da capo la propria macchina.
Quindi la peculiarità del Cloud Coretech è che tutte le risorse sono gestibili singolarmente e, ad esempio, se serve un disco aggiuntivo si può farlo a caldo. Non si può diminuire lo spazio su disco rispetto a quello acquistato alla sottoscrizione dell’offerta: purtroppo l’unica soluzione è rifare la macchina, ovvero prendere un disco aggiuntivo in trial delle dimensioni, giuste fare la migrazione dei dati e poi togliere quello originario. Questo perché il disco C è quello su cui risede la macchina virtuale e non si può modificare a caldo.
I server su Cloud Coretech si possono gestire dalla console centralizzata di Sygma, che viene proposta nell’immagine seguente, dove si vede la scheda di gestione delle VM.
Sotto la colonna VM List, che si trova alla destra del menu, vengono riportate le risorse assegnate alla macchina (al server in Cloud) e quindi indirizzi IP, CPU, RAM e disco.
Da questa console si possono compiere anche le operazioni di manutenzione: per esempio si possono eliminare (pulsante DELETE), aggiornare, spegnere e riavviare le macchine virtuali. Lo spegnimento e il riavvio sono operazioni che si rendono necessari se occorre aumentare a caldo delle risorse come RAM e CPU, perché in quel caso non è possibile modificarle come si fa con lo storage.
Lo spazio di storage è qualcosa da valutare attentamente nella scelta di un server Cloud, perché se si esaurisce durante l’utilizzo del sistema potrebbe bloccarsi il server; l’ideale sarebbe avere dimensioni illimitate, ma è qualcosa di poco sensato e poco praticabile.
In funzione del tipo di infrastruttura o di soluzione è necessario pensare alla scalabilità dello storage.
Se avete bisogno di un server che memorizzi dei video, delle immagini che vengono caricate quando si fanno delle query e queste questi file occupano molto spazio, probabilmente andarlo a ricercare nella tecnologia della macchina virtuale potrebbe non essere la soluzione ideale; in questo caso entrano in gioco soluzioni come i Bucket S3 e software tipo TNT Drive che consentono alla macchina virtuale, ad esempio Windows, di montare un Bucket S3 come se fosse un disco di rete. Per l’ambiente Linux esiste Fuse I/O.
Naturalmente quella di prendere un disco piccolo e all’occorrenza utilizzare istanze di rete per avere ulteriore storage magari su altri Cloud Provider non dev’essere un’escamotage per pagare di meno, ma una considerazione scaturita da valutazioni tecniche, perché non va scordato che a livello di latenza, di tempi di accesso, un’unità a disco nella stessa infrastruttura è molto meglio che una esterna in rete.
Performance e continuità operativa sono determinanti nella scelta di un Cloud, perché sono quelli che garantiscono l’attività dei server.
Nel Cloud Coretech vengono eseguiti monitoraggi continui dell’attività mediante due sistemi: una piattaforma di monitoring dalla quale andare a vedere i dati sia della macchina virtuale in termini di utilizzo di CPU, RAM, spazio su disco e stato della macchina virtuale, sia dati estrapolati da VMware sull’istanza selezionata, quindi dati che vanno dalla velocità del disco e tempi di latenza che VMware rileva sulla BM nell’accesso allo storage.
I dati vengono estratti da “sonde” che sono analizzatori software che forniscono i dati a VMware; da questi si costruiscono grafici di traffico e vari altri grafici come si vede nell’immagine seguente.
Questo è importante perché serve a capire perché magari una macchina virtuale sta avendo dei problemi.
Il monitoraggio permette dunque di avere una fotografia dell’infrastruttura e di mantenere i server sempre efficienti, rispondendo a eventuali domande dei clienti che magari non comprendono da dove nasce un problema.
Restando in tema, la piattaforma di gestione del Cloud Coretech, quindi Sygma, prevede l’invio di alert all’indirizzo di posta elettronica dell’utente corrispondente alla macchina monitorata quando viene superata una certe percentuale di utilizzo delle risorse o si verifica una condizione impostabile; questo permette di anticipare eventuali arresti o malfunzionamenti del server Cloud, ovvero di intervenire sulle applicazioni o acquistare risorse aggiuntive prima che sia tardi.
Per esempio se per almeno 5 minuti viene utilizzato il 95% della CPU (quindi vuol dire che i core non bastano e la macchina non funziona più bene) viene generato un alert; all’85% si innesca la condizone di warning.
All’interno di Sygma, dalla sezione Audit, è possibile vedere tutte le operazioni che sono state effettuate su ciascuna VM (ridimensionamento del disco, accessi effettuati tramite la console di Sygma ecc.); quindi ogni attività viene loggata.
Un momento importante del passaggio al Cloud è la migrazione dell’infrastruttura on-site (a casa del cliente) al Cloud Coretech o da un altro Cloud Provider sempre al Cloud Coretech.
Per effettuare la migrazione occorre della macchina fisica in casa del cliente o della macchina virtuale sempre in casa del cliente, è necessario accedere all’hypervisor del cliente o alla macchina, utilizzando una porta specifica (la 9089) da un IP specifico che Coretech fornirà.
Il primo step consiste nel fare un test, utilizzando ad esempio VMware vCenter Converter, grazie al quale ci si collega alla macchina origine e si esegue un test di importazione della macchina all’interno del Cloud Coretech. In pratica vCenter Converter è un agente di VMware specializzato nella migrazione, da installare sulla macchina da migrare, 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 consente di mettere in coda e monitorare più conversioni simultaneamente, in locale e in remoto, nella sede principale e nelle filiali.
Per effettuare la migrazione bisogna dunque collegarsi alla macchina da migrare, installare in essa la parte AGENT di VMware vCenter Converter (che richiede la porta 9089) conoscere l’indirizzo IP pubblico della macchina che si collegherà; poi servirà, per la gestione remota da console centralizzata, conoscere nome utente e password amministrativi della macchina virtuale in modo da potervi accedere. A quel punto vCenter Converter va a prendere la VM da migrare e la va a deployare sui cluster del Cloud Coretech.
Fatto ciò viene lanciata una prima sincronizzazione dei dati: si decidono uno o più momenti in cui rilanciare il processo di importazione o di conversione che può essere phisical to phisical o virtual to virtual (perché l’infrastruttura origine può essere fisica o virtuale), quindi si verifica quanto tempo occorre. La procedura si prova un paio di volte e a quel punto si pianifica la messa in produzione, ovvero il momento in cui iniziare la migrazione vera e propria e la messa in esercizio dell’infrastruttura su Cloud Coretech.
Nel terzo step si lancia la sincronizzazione, si spengono i servizi (magari si disabilita una scheda di rete) che ci sono sulle macchine di produzione, si esegue l’ultima sincronizzazione e si accende la macchina virtuale, si esegue un ulteriore test per vedere che tutto sia sia posto e si avvia la pubblicazione, cioè si affaccia la macchina a un IP pubblico se c'è un firewall. Da quel momento la macchina è in produzione.
Chiaramente il passaggio impone un tempo di fermo, di arresto del servizio, che mediamente è una mezz’ora dall’ultima sincronizzazione, almeno se le macchine virtuali non sono grandissime e la connettività è sufficientemente affidabile e veloce.
Nel caso di VM con sistema operativo Windows è necessario che prima della migrazione siano stati installati tutti gli aggiornamenti e che la macchina sia stata riavviata dopo gli aggiornamenti stessi; inoltre occorre verificare che non ci sia in sospeso un aggiornamento o un riavvio durante la migrazione, perché in tal caso occorre ripetere la sincronizzazione ij quanto la macchina deployata in Cloud sarà diversa da quella che si sta migrando.
In tal caso le sincronizzazioni successive ci metteranno molto più tempo perché devono sincronizzare tutti gli aggiornamenti.
La migrazione è dunque semplicissima; chiaro che se l’infrastruttura da migrare è composta da macchine datate non è possibile trasferirle tali e quali, ma bisogna rifare l’installazione da zero, con una procedura più lunga.
