Archivi categoria: migrazione

Migrazione di server fisici verso Microsoft Azure con Azure Site Recovery

Facebooktwittergoogle_plusredditlinkedin

Anche se ormai gran parte delle nostre infrastrutture sono virtualizzate, potrebbe capitare che in alcune aziende ci siano ancora delle macchine fisiche. Azure Site Recovery è una funzionalità offerta da Microsoft Azure per poter effettuare il disaster recovery dei nostri server fisici oppure per poterli definitivamente migrare verso il Cloud.

In questo articolo ci occuperemo della migrazione dei server fisici, ma se siete interessati alla migrazione di macchine virtuali vi invito a leggere l’articolo https://www.ictpower.it/sistemi-operativi/migrazione-di-macchine-virtuali-vmware-verso-microsoft-azure-con-azure-site-recovery.htm e l’articolo https://www.ictpower.it/sistemi-operativi/migrazione-delle-macchine-virtuali-vmware-verso-microsoft-azure-con-lutilizzo-di-azure-migrate.htm

Per eseguire la migrazione di un server fisico è necessario abilitare la replica del server ed eseguirne il failover in Azure.

Creazione del Recovery Service Vault

Il Recovery Service Vault è un servizio di Azure che ospita i dati e le configurazioni delle macchine virtuali. Per sapere nel dettaglio le caratteristiche del servizio potete leggere l’articolo https://docs.microsoft.com/it-it/azure/backup/backup-azure-recovery-services-vault-overview

Per creare un nuovo Recovery Service Vault è sufficiente aprire il portale di Azure e, facendo clic su New, cercare Backup and Site Recovery (OMS). Inserite quindi il nome del vostro Vault, il Resource group da utilizzare e la location dove volete che venga creato, come mostrato in figura:

Figura 1: Creazione di un nuovo Azure Recovery Vault

Terminata la creazione del Vault ne potete visualizzare le caratteristiche utilizzando la scheda Overview. Cliccate sulla scheda Site Recovery e iniziate la preparazione dell’infrastruttura, indicando cosa volete proteggere (Protection Goal). Nel mio caso, visto che voglio proteggere delle macchine fisiche on-premises, ho dichiarato che le macchine non sono virtualizzate, come indicato in figura:

Figura 2: Preparazione del Protection Goal

Nel secondo passaggio vi verrà chiesto di scaricare e testare il Deployment Planner, uno strumento gratuito che vi consente di profilare i vostri server fisici senza alcun impatto sulla produzione e di determinare i requisiti di larghezza di banda e spazio di archiviazione di Azure per le operazioni di replica e failover. Vi consiglio di leggere l’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-deployment-planner per conoscere le potenzialità di questo strumento.

Figura 3: Deployment Planning

Nel passaggio successivo dovrete selezionare il Configuration Server da utilizzare per la replica dei dati della vostra macchina fisica. Il Configuration Server funge da coordinatore tra i servizi di Site Recovery e l’infrastruttura locale (on-premises). Per i requisiti hardware e software del Configuration Server vi rimando all’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-vmware-to-azure-manage-configuration-server. Provvedete a scaricare il Microsoft Azure Site Recovery Unified Setup (sono circa 1,5 GB) e ad installarlo nella vostra infrastruttura in una macchina Windows Server 2012 R2 (va bene anche la versione Evaluation e la macchina può essere anche in workgroup). Seguite tutte le istruzioni indicate nel blade del portale Azure, come mostrato in figura:

Figura 4: Aggiunta del Configuration Server e procedura di installazione

Installazione di Microsoft Azure Site Recovery Unified Setup

L’installazione del software che provvederà a creare il nostro Configuration Server è molto semplice ed è descritta nelle immagini che seguono. Assicuratevi di rispettare i Requisiti di dimensione per un server di configurazione e, dopo aver installato un server con Windows Server 2012 R2, dategli un IP statico e lanciate il setup di configurazione.

Figura 5: Prima schermata di installazione del Configuration Server

Figura 6: Inserimento della Site Recovery Registration Key che avete precedentemente scaricato dal portale di Azure

Figura 7: Verifica dei prerequisiti per l’installazione del Configuration Server

Figura 8: Inserimento della password di root e di svsystems user per il database MySQL

Figura 9: Indicazione che vogliamo proteggere server fisici e non macchine virtuali

Figura 10: Schermata riassuntiva del Setup del Configuration Server

Figura 11: Installazione del Configuration Server completata

A questo punto vi verrà chiesto di riavviare. Terminato il riavvio del server, subito dopo il login, vi apparirà il messaggio che vi indica quale sarà la passphrase da utilizzare per collegare l’agent del Mobility Service al vostro Configuration Server. Il Mobility Service è un servizio che si occupa di trasferire i file generati dal vostro server fisico verso il Configuration Server, che si occuperà poi di inoltrarli Ad Azure Site Recovery. Salvate la passphrase in un file di testo, perché potrebbe esservi richiesta se vorrete installare manualmente l’agent di Azure Site Recovery Mobility Service. In ogni caso è sempre possibile rigenerarla seguendo le indicazioni contenute nell’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-vmware-to-azure-manage-configuration-server

Figura 12: Passpharse per il collegamento degli agent di Azure Site Recovery al Connection Server

Lanciate dal Desktop il collegamento al Cspsconfigtool, che vi darà la possibilità di aggiungere le credenziali per installare il Mobility Service sulle vostre macchine fisiche. Esistono diverse modalità di installazione di questo servizio e per approfondimenti vi rimando alla lettura dell’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-vmware-to-azure-install-mob-svc

Figura 13: Aggiunta dell’account necessario all’installazione del Mobility Service sulle macchine fisiche

Terminata l’installazione del Configuration Server potete tornare nel portale Azure e dal blade dello Step 3 adesso sarà possibile selezionare il server appena installato, come mostrato in figura:

Figura 14: Selezione del Connection Server appena installato

Proseguite con lo Step 4, indicando la Subscription Azure da utilizzare, il Deployment model e assicurandovi di avere uno storage account ed una virtual network dove migrare i vostri server fisici on-premises.

Figura 15: Individuazione del target Azure dove replicare le macchine fisiche on-premises

L’ultimo passaggio di preparazione dell’infrastruttura consiste nella creazione di una Replication Policy da associare al vostro Configuration Server. La Replication Policy stabilisce la frequenza di replica delle vostre macchine fisiche on-premises. Maggiori informazioni sono disponibili al link https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-setup-replication-settings-vmware

Figura 16: Creazione di una Replication Policy da associare al Configuration Server

Verranno create ed associate due Replication Policy: una per il Failover ed un’altra per il Failback, come mostrato in figura:

Figura 17: Creazione ed associazione delle Replication Policy

Completate la preparazione della vostra infrastruttura facendo clic sul pulsante OK.

Figura 18: Completamento della preparazione dell’infrastruttura

Replica dei server fisici

Per dichiarare quali sono i server fisici da replicare con Azure Site Recovery fate clic sulla scheda Step 1: Replicate Application e configurate il Source con i parametri inseriti in figura:

Figura 19: Configurazione del Source per la Replica

Configurate nel secondo passaggio il Target del Recovery, in particolar modo indicando lo Storage Account dove verranno salvati i dati dei server fisici e la rete virtuale dove collegare le macchine replicate in Azure.

Figura 20: Configurazione del Target in Azure Site Recovery

Nel terzo passaggio indicate quali sono i server fisici da replicare in Azure, indicando un nome, l’indirizzo IP e il tipo di sistema operativo, come mostrato in figura:

Figura 21: Scelta dei server fisici da replicare in Azure

Figura 22: Aggiunta dei server fisici da replicare in Azure

Dichiarate quale sarà l’account (che avete precedentemente creato sul Configuration Server) da utilizzare per l’installazione dell’agent di Mobility Service sulle macchine fisiche, e quali dischi del server fisico volete escludere dalla replica, come mostrato in figura:

Figura 23: Configurazione delle proprietà della replica, scelta dell’account per l’installazione del Mobility Service

L’ultimo passaggio vi chiede di confermare quale Replication Policy utilizzare per la replica dei server fisici scelti.

Figura 24: Replication Policy da utilizzare per la replica dei server fisici scelti

Completate lo Step 1: Replicate Application cliccando sul pulsante Enable Replication.

Figura 25; Completamento dello Step 1: Replicate Application e abilitazione della replica

Lo Step 2: Manage Recovery Plans consiste nella creazione di un Recovery Plan (o piano di ripristino), che permette di stabilire quali macchine devono essere avviate ed in quale ordine. Aggiungetene un nuovo Recovery Plan e configuratelo con i parametri richiesti, come mostrato in figura:

Figura 26: Creazione di un nuovo Recovery Plan

A questo punto il Configuration Server installerà il Mobility Service sui server fisici che avete deciso di migrare e abiliterà la replica della macchina. Potete anche installare manualmente il Mobility Service usando la procedura indicata dall’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-vmware-to-azure-install-mob-svc#install-mobility-service-manually-by-using-the-gui. Il file di installazione dell’agent si trova nel percorso C:\ProgramData\ASR\home\svsystems\pushinstallsvc\repository del Configuration Server.

Figura 27: Abilitazione della replica

Dopo circa 20 minuti dall’abilitazione, inizierà la replica dei dati verso Azure Site Recovery. Attendete che tutti i dati siano stati replicati visualizzando la scheda Replicated Items del vostro Azure Site Recovery Vault.

Figura 28: replica dei dati del server fisico completata

Failover Test

Per verificare che tutto funzioni correttamente è necessario testare il Failover della macchina virtuale presente in Azure. Cliccando su Replicated Items nel Recovery Service Vault dal portale di Azure, selezionate la macchina virtuale da testare e dal menù scegliete Test Failover, come mostrato in figura:

Figura 29: Test failover della macchina virtuale in Azure

Nel blade che vi si aprirà scegliete il Recovery Point da testare e la rete virtuale a cui collegare la VM di test. Cliccate su OK e attendete alcuni minuti fino a quando la VM di test non sarà stata creata.

Figura 30: Scelta del Recovery Point e della rete virtuale per il test del Failover

Collegatevi alla VM di test che è stata creata in Azure ed effettuate tutte le verifiche che ritenete necessarie per assicurarvi che la vostra macchina abbia tutti i dati e che funzioni correttamente. Al termine di tutte le procedure di controllo, sarà possibile effettuare il Cleanup test failover, che distruggerà la VM Azure di test che è stata creata.

Figura 31: Test failover Cleanup

Cliccando su Replicated Items nel Recovery Service Vault dal portale di Azure è possibile configurare le proprietà della macchina replicata. Potete scegliere il nome che verrà visualizzato in Azure, il Resource Group dove metterla, la dimensione della VM, la virtual network ed anche dargli un IP statico. Nel caso ne abbiate i diritti, attivate l’Hybrid Use Benefit, che vi permette un risparmio considerevole sulle licenze del sistema operativo. Maggiori informazioni sull’Hybrid Use benefit le trovate leggendo l’articolo https://docs.microsoft.com/it-it/azure/virtual-machines/windows/hybrid-use-benefit-licensing

Figura 32: Configurazione dei parametri della VM

Migrazione della macchina fisica in Azure

Per completare la migrazione della macchina fisica è necessario effettuare due passaggi: Failover e Complete Migration. Prima di eseguire un failover, eseguite sempre un failover di test per verificare che tutto funzioni come previsto. Maggiori dettagli sono disponibili leggendo l’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-failover

Figura 33: Failover della macchina fisica

Terminata la procedura di Failover ed dopo esservi accertati che tutto funzioni perfettamente, potete effettuare la procedura di Complete Migration. Il processo di migrazione viene completato, viene arrestata la replica della macchina virtuale e viene arrestata la fatturazione di Site Recovery per la macchina virtuale. D’ora in poi pagherete però l’esecuzione delle VM in Azure.

Figura 34: Completamento della migrazione

Conclusioni

Migrare i server fisici verso Azure è un’operazione molto semplice se viene effettuata con Azure Site Recovery. Per eseguire la migrazione di un server è sufficiente abilitare la replica del server ed eseguirne il failover in Azure. In questo modo l’intera macchina, con tutti i dati, viene migrata con un minimo downtime e senza impatto sull’infrastruttura e sulla produzione. Migrare i server fisici verso il Cloud non è mai stato così facile!

Migrazione delle macchine virtuali VMware verso Microsoft Azure con l’utilizzo di Azure Migrate

Facebooktwittergoogle_plusredditlinkedin

Pochi mesi fa è stato annunciato un nuovo servizio chiamato Azure Migrate https://azure.microsoft.com/it-it/blog/announcing-azure-migrate/

Obiettivo di questo servizio è semplificare la migrazione delle macchine virtuali VMware vSphere verso il cloud di Microsoft Azure e di fornirvi assistenza attraverso tutti passaggi necessari per poterla effettuare, dall’assessment alla migrazione vera e propria. Dopo aver individuato le informazioni sulle macchine virtuali VMware ospitate nel Datacenter locale (utilizzo di CPU e memoria, dimensioni del disco e connessione alle diverse reti), sarà possibile ottenere consigli sul corretto dimensionamento delle risorse cloud (come ad esempio la dimensione della VM ospitata in Azure), in modo tale da avere un maggior controllo sui costi di migrazione in base ad un utilizzo efficiente della VM in Azure.

Dopo aver eseguito una valutazione della propria infrastruttura on-premises con Azure Migrate, sarà possibile quindi iniziare la migrazione delle macchine virtuali locali verso Azure, utilizzando i servizi messi a disposizione da Microsoft, come ad esempio Azure Site Recovery e Azure Database Migration Service.

Azure Migrate consente quindi di:

  • Valutare l’idoneità per Azure: valutare se le VM on-premises possono essere eseguite in Azure.
  • Ottenere informazioni sulle dimensioni consigliate: ottenere informazioni per dimensionare correttamente le VM in Azure in base alla cronologia delle prestazioni delle macchine virtuali on-premises.
  • Stimare i costi mensili: ottenere una stima dei costi per l’esecuzione delle VM in Azure.
  • Facilitare la migrazione: visualizzare le dipendenze delle VM on-premises per creare gruppi di VM di cui eseguire la migrazione insieme.

Figura 1: Principio di funzionamento di Azure Migrate

Per cominciare a familiarizzare con questo nuovo strumento potete collegarvi al portale di Azure e cercare Azure Migrate. Attualmente la funzionalità è in Preview.

Figura 2: Ricerca della funzionalità di Azure Migrate (Preview) nel portale di Azure

Cliccate sul pulsante Create e iniziate un nuovo progetto di migrazione, inserendo tutti i parametri richiesti, come mostrato in figura. Attualmente è possibile creare un progetto Azure Migrate solo nell’area Stati Uniti centro-occidentali (West Central US). Ciò non impedisce, tuttavia, di pianificare una migrazione per una diversa regione di Azure di destinazione e quindi ad esempio eseguire le macchine virtuali in West Europe. La località del progetto di migrazione viene usata solo per l’archiviazione dei metadati individuati nell’ambiente on-premises e che serviranno successivamente a definire il progetto.

Figura 3: Creazione del nuovo progetto di migrazione

La prima operazione da effettuare consiste nel “Discover & Assess“, che si compone essenzialmente di due fasi: Il primo step consiste nell’individuare quali sono le macchine virtuali VMware presenti nella propria infrastruttura, mentre il secondo step consiste nel creare un assessment. È possibile individuare fino a 1000 VM in una singola individuazione (discover) e fino a 1500 VM in un singolo progetto. È inoltre possibile valutare fino a 400 VM in una singola valutazione (assess).

Figura 4: Discover e Assess – Schermata iniziale per l’avvio delle due fasi

Figura 5: Prima fase – Individuazione dell’ambiente on-premises e delle VM VMware

Dopo aver cliccato sul pulsante “Discover machines” vi verrà presentata una pagina con 4 passaggi da effettuare. Azure Migrate usa una VM da far girare on-premises (una appliance) con a bordo un agente che si occuperà di raccogliere ed individuare i computer on-premises. Per utilizzare l’appliance, scaricate il file di installazione in formato Open Virtualization Appliance (con estensione OVA) e importatelo come macchina virtuale nel server vCenter locale.

Figura 6: Download della virtual appliance di Azure Migrate

Figura 7: importazione della virtual appliance di Azure Migrate nel vCenter locale

Figura 8: Schermata finale prima dell’importazione dell’appliance di Azure Migrate

  1. Terminata l’importazione dell’appliance, procedete al suo avvio e configuratela. L’appliance è una macchina virtuale con Windows Server 2012 R2 e sul desktop troverete un link chiamato “Run Collector” che farà partire l’agente di raccolta che si occuperà dell’individuazione delle VM on-premises. L’agente di raccolta raccoglie i metadati delle VM usando cmdlet di VMware PowerCLI. L’individuazione non comporta installazioni nelle VM o negli host VMware e i metadati raccolti includono informazioni sulle VM come numero di core, quantità di memoria, numero di dischi, dimensioni dei dischi e schede di rete. Vengono anche raccolti dati sulle prestazioni delle VM, tra cui utilizzo di CPU e memoria, operazioni di I/O al secondo e velocità effettiva (in MBps) dei dischi e output di rete (in MBps).

Figura 9: Installazione dei prerequisiti del Collector di Azure Migrate

Figura 10: Connessione al vCenter da parte del Collector di Azure Migrate

Dopo aver terminato l’installazione dei prerequisiti ed esservi connessi al VMware vCenter on-premises, inserite il Project ID e la Project Key che sono stati generati durante la creazione del progetto di Azure Migrate e che sono disponibili sul portale di Azure, come mostrato in figura:

Figura 11: Inserimento dei dati del progetto di migrazione

A questo punto comincerà l’individuazione delle vostre macchine virtuali, che potrebbe durare qualche minuto (dipende dal numero delle VM che avete on-premises).

Figura 12: Raccolta delle informazioni da parte del Collector di Azure Migrate

Dopo alcuni minuti, potrete tornare nel portale Azure e visualizzare un messaggio che vi avvisa che l’individuazione delle VM è terminata e che è possibile passare alla seconda fase, quella dell’assessment.

Figura 13: Discover delle VM on-premises completato

Il processo di individuazione può essere ripetuto anche diverse volte, cliccando su Discover
machines e seguendo le istruzioni riportate nel blade, come mostrato in figura:

Figura 14: Ripetizione del processo di individuazione delle VM on-premises

Creazione dell’assessment

Un assessment è un gruppo di macchine virtuali che devono essere migrate insieme. Nel mio caso ho bisogno di migrare una WebApp composta da un database di backend e da due web server di frontend. Dal portale di Azure cliccate quindi sul vostro progetto di migrazione e sul pulsante “Create assessment“. Nella schermata che vi si aprirà date un nome al gruppo di macchine da migrate (nel mio caso l’ho chiamato WebApp) e selezionate le VM da migrare, come mostrato in figura:

Figura 15: Creazione del gruppo di macchine da migrare (assessment)

Cliccando sull’assessment appena creato potrete avere una Overview delle informazioni che sono state raccolte dall’appliance di Azure Migrate. In particolar modo potrete vedere tutte le macchine virtuali che possono essere migrate ad Azure senza problemi ed il loro costo mensile stimato, sia per il computing che per lo storage. Facendo clic su Edit properties avrete anche la possibilità di modificare alcuni parametri, come ad esempio la Region di destinazione ed il tipo di valuta.

Figura 16: Overview dell’assessment

Nella Azure readiness potrete anche avere un dettaglio delle diverse VM da migrare con la dimensione che dovranno avere le rispettive macchine Azure.

Figura 17: Azure readiness delle VM on-premises

Per sapere qual è il modo migliore di migrare le vostre macchine virtuali (che apparirebbe nella colonna SUGGESTED TOOL) è necessario installare un agente nelle VM on-premises. L’agente vi aiuterà anche a valutare le diverse dipendenze tra le VM. Per maggiori informazioni fate riferimento alla pagina https://docs.microsoft.com/it-it/azure/migrate/how-to-create-group-machine-dependencies#prepare-machines-for-dependency-mapping

Figura 18: dettaglio dei costi per ogni singola VM

È anche possibile esportare l’assessment in formato Excel, per avere una reportistica dettagliata, come mostrato in figura:

Figura 19: Esportazione dell’assessment in formato Excel

Migrazione delle macchine virtuali VMware verso Azure

Adesso che avete completato l’individuazione delle VM on-premises e avete valutato il vostro ambiente, siete pronti per migrare verso il Cloud. Per poterlo fare potete utilizzare lo strumento Azure Site Recovery e seguire i passaggi descritti nell’articolo https://www.ictpower.it/guide/protezione-delle-macchine-virtuali-vmware-e-dei-server-fisici-con-azure-site-recovery.htm

Conclusioni

Il servizio Azure Migrate vi permette di individuare le macchine virtuali VMware idonee per la migrazione verso il cloud Azure e vi fornisce degli strumenti di analisi che vi daranno anche la possibilità di stimare i costi di mantenimento della vostra infrastruttura. Se volete esercitarvi con questo nuovo strumento, che per il momento è ancora in Preview, potete utilizzare questo Laboratorio pratico su Azure Migrate. Interessante è anche il video Migrating to Azure using Azure Migrate and Azure Site Recovery – BRK3243 , registrato durante la conferenza Ignite 2017.

Migrare una macchina fisica Linux verso Microsoft Azure

Facebooktwittergoogle_plusredditlinkedin

Al giorno d’oggi, nella gestione di infrastrutture, può capitare di dover effettuare migrazioni di macchine fisiche verso il cloud. Questa operazione richiede un’attenta analisi dello scenario e una procedura dettagliata che può variare in base al sistema operativo che si vuol migrare.

In questa guida analizzeremo tutti gli step necessari per migrare una macchina fisica Ubuntu 16.04 verso i servizi cloud di Azure.

La prima fase racchiude tutte le operazioni relative alla preparazione della macchina nel rispetto dei requisiti di Azure.

1. Nella macchina fisica è necessario aggiornare gli archivi con quelli di Azure in /etc/apt/sources.list

Per effettuare l’operazione basterà eseguire da terminale:

# sudo sed -i 's/[a-z][a-z].archive.ubuntu.com/azure.archive.ubuntu.com/g' /etc/apt/sources.list

# sudo apt-get update

2. È necessario aggiornare il sistema operativo al kernel più recente eseguendo i comandi seguenti:

# sudo apt-get update

# sudo apt-get install linux-generic-hwe-16.04 linux-cloud-tools-generic-hwe-16.04

# sudo apt-get dist-upgrade

# sudo reboot

3. Modificare la configurazione di avvio del kernel per Grub in modo da includere ulteriori parametri del kernel per Azure.

Per fare questo, editare il /etc/default/grub e modificare la stringa GRUB_CMDLINE_LINUX_DEFAULT nel seguente modo:

GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0,115200n8 earlyprintk=ttyS0,115200 rootdelay=300"

4. Dopo la modifica lanciare sudo update-grub per aggiornare la configurazione.

5. Per poter interfacciare la macchina con i servizi di Azure è necessario installare l’Agente Linux di Azure. L’installazione di questa componente avviene attraverso i seguenti comandi:

# sudo apt-get update

# sudo apt-get install walinuxagent

6. Successivamente è necessario effettuare il deprovisioning della macchina e prepararla per il provisioning in Azure:

# sudo waagent -force -deprovision

# export HISTSIZE=0

# logout

La seconda fase racchiude tutte le operazioni necessarie per convertire la macchina fisica in un’immagine. In questa fase ci avvarremo dell’utilizzo di due strumenti:

  • DD è una componente di Linux comunemente usata per creare le immagini di un disco e produrne un file immagine
  • VHDTool è uno strumento per Windows utilizzato per manipolare i file VHD (Download: http://bit.ly/1FWQzVx)
1. Per creare l’immagine del disco della macchina bisogna lanciare il seguente comando:

dd if=/dev/sda of=/mnt/my_ubuntu_disk.img

dove sda fa riferimento all’intero disco della macchina e my_ubuntu_disk.img è il nome di dell’immagine che andremo a creare all’interno di un mount point che potrà essere un disco esterno oppure una share di rete.

N.B. L’operazione potrebbe durare molto tempo in caso di disco di grosse dimensioni. Il prompt non darà alcun feedback fino al termine dell’operazione. È possibile monitorare lo stato della creazione dell’immagine dalle variazioni della dimensione del file.

DD crea l’immagine includendo anche lo spazio vuoto. Eventualmente è possibile usare ulteriori tool per ridurre la dimensione dell’immagine. È pertanto necessario utilizzare uno spazio di appoggio sufficientemente grande.

2. Dal prompt dei comandi di Windows lanciare VHDTool /convert c:\my_ubuntu_disk.img

3. Rinominare il file my_ubuntu_disk.img con estensione .vhd

Nella terza fase si procederà all’upload del VHD su Azure e alla creazione della macchina virtuale.

1. Tramite l’interfaccia della riga di comando di Azure 2.0 accedere alla sottoscrizione attraverso il comando az login

2. Creare un gruppo di risorse. I gruppi di risorse riuniscono in modo logico tutte le risorse di Azure a supporto delle macchine virtuali. Per creare il gruppo eseguire: az group create –name myResourceGroup –location westus

3. Creare un account di archiviazione per il VHD nel gruppo di risorse appena creato con il comando:

az storage account create --resource-group myResourceGroup --location westus \

     --name mystorageaccount --kind Storage --sku Standard_LRS

4. Generare le chiavi di accesso per l’account di archiviazione:

az storage account keys list --resource-group myResourceGroup --account-name mystorageaccount

Al termine dell’esecuzione del comando, prendere nota del valore di key1 poiché verrà utilizzato per accedere all’account di archiviazione.

5. Creare un contenitore di archiviazione per organizzare i dischi in modo logico:

az storage container create --account-name mystorageaccount \

--account-key valoredikey1 --name mydisks

6. Il seguente passaggio permetterà l’effettivo caricamento del VHD su Azure:

az storage blob upload --account-name mystorageaccount \

--account-key key1 --container-name mydisks --type page \

--file /path/to/disk/my_ubuntu_disk.vhd --name myUbuntu.vhd

7. Per creare una macchina virtuale dal disco rigido virtuale, occorre convertire innanzitutto il disco rigido virtuale in un disco gestito con il comando:

az disk create --resource-group myResourceGroup --name myManagedDisk \

--source https://mystorageaccount.blob.core.windows.net/mydisks/myUbuntu.vhd

8. Una volta creato il disco gestito, lanciando il seguente comando, si otterrà il suo URI di cui prenderemo nota:

az disk list --resource-group myResourceGroup \

    --query '[].{Name:name,URI:creationData.sourceUri}' --output table

9. Infine, per creare la macchina virtuale:

az vm create --resource-group myResourceGroup --location westus \

--name myVirtualMachine --os-type linux \

--admin-username miouser --admin-password miapassword \

--attach-os-disk uri_del_disco

Una volta terminata la procedura, avremo riprodotto la macchina fisica sul cloud di Azure. Da questo momento del completamento del deploy, potremo gestire la macchina dal portale di Azure.


Bisognerà effettuare delle verifiche sull’apertura degli endpoint corrispondenti ad eventuali porte configurate sulla macchina fisica. Inoltre, grazie ai servizi cloud, sarà possibile completare la configurazione aggiungendo nuove funzionalità alla macchina come ad esempio un set di disponibilità.

Migrare dal Classic Model al Resource Manager Model in Microsoft Azure

Facebooktwittergoogle_plusredditlinkedin

In questo articolo vedremo come sia possibile migrare le risorse IAAS (Infrastructure As A Service) di Microsoft Azure dal modello Classico a ARM (Azure Resource Manager) senza nessun tipo di downtime.

Gli attuali scenari supportati sono 3:

  • Migrazione di VM senza rete virtuale
  • Migrazione di VM collegate ad una rete virtuale
  • Migrazione degli storage account

Tutte le operazioni di migrazione dovranno essere fatte utilizzando delle cmdlet Powershell. Quindi come prima operazione collegatevi al link Azure PowerShell e installate le cmdlet di Azure.

Figura 1: Installazione di Azure Powershell

Terminata l’installazione loggatevi al vostro Tenant di Azure utilizzando la cmdlet

Login-AzureRmAccount

Figura 2: Connessione al tenant di Azure

Nel caso abbiate più sottoscrizioni potete usare la cmdlet

Get-AzureRMSubscription

per poterle visualizzare e la cmdlet

Get-AzureRmSubscription –SubscriptionName NomeDellaSottoscrizione Select-AzureRmSubscription

per poter selezionare la sottoscrizione di vostro interesse

Figura 3: Sottoscrizioni disponibili

Come prima operazione è necessario registrare la sottoscrizione per la migrazione con la cmdlet

Register-AzureRmResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate

È possibile verificare che la sottoscrizione sia stata registrata correttamente lanciando la cmdlet

Get-AzureRmResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate

Figura 4: Sottoscrizione registrata per la migrazione

Dovete collegarvi contemporaneamente utilizzando anche il Classic Model. Per farlo vi basta lanciare la cmdlet
Add-AzureAccount
, inserire le credenziali di autenticazione, visualizzare tutte le sottoscrizioni con la cmdlet
Get-AzureSubscription
e selezionare quella che vi interessa con la cmdlet
Select-AzureSubscription -SubscriptionName NomeDellaSottoscrizione

Figura 5: Collegamento al Classic model

Adesso che siete loggati ad entrambi i modelli di gestione (Classic e ARM) potete procedere alla migrazione.

Migrazione di macchine virtuali senza una VNET collegata

Se avete delle macchine virtuali che non sono collegate a delle VNET dovete, come prima operazione, ottenere la lista di tutti i Cloud Service eseguendo la cmdlet

Get-AzureService ft Servicename

Una volta individuato il Cloud Service che vi interessa (nel mio caso ho un Cloud Service chiamato NICVM00), ottenete il DeploymentName utilizzando la cmdlet

(Get-AzureDeployment -ServiceName NICVM00).DeploymentName

Figura 6: Cloud Service Name e Deployment Name

Nel mio caso per preparare la migrazione mi basta lanciare la cmdlet

Move-AzureService -Prepare -ServiceName NICVM00 -DeploymentName NICVM00 -CreateNewVirtualNetwork

Questa cmdlet ci metterà un po’ a completarsi. Vengono eseguite diverse operazioni, tra cui quella di verificare se ci sono i prerequisiti per la migrazione sia a livello di VM, di configurazione e di storage, per poter essere certi che non ci sarà nessun tipo di downtime durante la migrazione.

Ad operazione terminata vi apparirà il messaggio mostrato in figura:

Figura 7: Preparazione della migrazione effettuata con successo

Durante la fase di preparazione sono stati creati due endpoint diversi che puntano alla stessa risorsa (in questo caso la macchina virtuale NICVM00). In questo modo la macchina ora è accessibile da entrambe le modalità di management (Classic mode e ARM):

Figura 8: Preparazione della migrazione e accessibilità da entrambe le modalità di management

La macchina è visibile dal nuovo portale https://portal.azure.com e risulta inserita in un nuovo Resource Group chiamato NICVM00-Migrated

Figura 9: macchina “migrata” in un nuovo Resource Group

Termine della procedura di migrazione della macchina virtuale

Siamo pronti per terminare la procedura di migrazione. Per poterlo fare possiamo confermare con Commit o annullare con Abort. Confermo con la cmdlet

Move-AzureService -Commit -ServiceName NICVM00 -DeploymentName NICVM00

E ottengo il risultato mostrato in figura:

Figura 10: Operazione di Commit completata con successo

Tutte le dipendenze della macchina virtuale sono state migrate e la macchina non sarà più visibile dal vecchio portale. Dal nuovo portale invece potete vedere il nuovo Resource Group creato dopo la migrazione:

Figura 11: Nuovo Resource Group creato dopo la migrazinoe

Migrazione di una VNET con tutte le VM ad essa collegate

Per poter migrare una rete virtuale con tutte le macchine virtuali collegate occorre seguire pochi semplici passaggi. Nel mio caso la rete da migrare si chiama nicvnet2016, a cui è collegata una macchina virtuale chiamata NICVM01

Figura 12: rete da migrare

Come prima operazione ho lanciato la cmdlet
Move-AzureVirtualNetwork -Prepare -VirtualNetworkName nicvnet2016
per preparare la migrazione.

Figura 13: Preparazione della rete

In questo modo adesso la macchina virtuale a cui era collegata la rete è visibile da entrambi i portali. Basta infatti andare nel nodo Virtual Machines del nuovo portale di Azure (https://portal.azure.com) e verificare che la macchina NICVM01 risulta in stato di Updating ed è collegata al Resource Group NICVM01-Migrated

Figura 14: VM visibile nel nuovo portale

Adesso che la macchina è visibile dal nuovo portale mi sono collegato in desktop remoto e ne ho verificato tutte le funzionalità.

Termine della procedura di migrazione della rete virtuale

Siamo pronti per terminare la procedura di migrazione. Per poterlo fare possiamo confermare con Commit o annullare con Abort. Confermiamo con la cmdlet

Move-AzureVirtualNetwork -Commit -VirtualNetworkName nicvnet2016

E dopo qualche minuto la rete virtuale con tutte le macchine virtuali collegate sarà stata migrata al nuovo modello di management basato su Azure Resource Manager (ARM).

Figura 15: Conferma della migrazione al nuovo modello di gestione di Azure

Nel vecchio portale non vedrete più né la rete virtuale né le VM collegate e d’ora in poi tutta la gestione verrà fatta dal nuovo portale di Azure. Infatti troverete un nuovo Resource Group con il nome del Cloud Service seguito dalla parola –Migrated

Migrazione dello storage account

Dopo aver migrato le macchine virtuali è consigliato migrare anche lo storage account che le contiene. Come prima operazione prepariamo lo storage account per la migrazione seguendo la cmdlet

Move-AzureStorageAccount -Prepare -StorageAccountName NomeDelloStorageAccount

Esattamente come nel caso della rete, potete decidere se confermare con Commit o annullare con Abort. Confermiamo con la cmdlet

Move-AzureStorageAccount -Commit -StorageAccountName NomeDelloStorageAccount

Conclusioni

Migrare al nuovo modello di management di Azure è velocissimo, non prevede nessun tipo di downtime e si può fare con poche cmdlet Powershell. Per maggiori informazioni vi rimando al link http://aka.ms/classicmigration

Upgrade domain controller a Windows Server 2016 Parte 4 di 4

Facebooktwittergoogle_plusredditlinkedin

Con l’uscita di Windows Server 2016 molte infrastrutture prenderanno la decisione di aggiornare i propri Domain Controller in particolar modo se ancora ne hanno alcuni basati su Windows Server 2003. La dismissione dei Domain Controller Windows Server 2003 consente infatti di trarre vantaggio dalle numerose funzionalità che sono state introdotte in Active Directory rispetto a Windows Server 2003 che rappresenta la versione di sistema operativo più datata da cui è ancora possibile eseguire la migrazione. Nel quarto dei quattro articoli sull’analisi le problematiche relative all’aggiornamento di un’infrastruttura Active Directory basata su Domain Controller Windows Server 2003 verrà analizzata la migrazione della replica SYSVOL da FRS a DFS.

Il primi tre articoli sono disponibili ai seguenti:

Argomenti

  • Vantaggi della replica SYSVOL tramite DFS e pianificazione della migrazione da FRS a DFS
  • Verifica dei prerequisiti e della funzionalità della replica FRS
  • Migrazione del dominio nello stato Prepared
  • Migrazione del dominio nello stato Redirect
  • Migrazione del dominio nello stato Eliminated
  • Conclusioni

Vantaggi della replica SYSVOL tramite DFS e pianificazione della migrazione da FRS a DFS

I Domain Controller utilizzano la directory condivisa SYSVOL per replicare tra loro gli script di logon e i file delle Group Policy. In Windows Server 2000 e Windows Server 2003 la replica della directory SYSVOL avviene tramite File Replication Service (FRS). A partire da Windows Server 2008 viene utilizzata invece la replica DFS se il livello funzionale del domino è Windows Server 2008, in caso contrario si continua ad utilizzare FRS.

Questo significa che nell’infrastruttura di esempio dal momento che il livello funzionale è Windows Server 2003 la replica della directory SYSVOL avviene tramite FRS e non tramite la nuova replica DFS che offre maggior efficienza, maggior scalabilità, utilizza l’algoritmo Remote Differential Compression (RDC) che riduce l’utilizzo della banda di rete e ha un meccanismo di auto ripristino da eventuali corruzioni.

Di seguito lo schema dell’infrastruttura a cui faremo rifermento in cui è presente un DC Windows Server 2016 VSDC2016 e la replica della SYSVOL avviene tramite l’FRS.

In scenari come quello dell’esempio risulta quindi necessario eseguire manualmente la migrazione dalla replica FRS alla replica DFS, sino a che la migrazione non è terminata non devono essere apportate modifiche a script di logon e Group Policy. Durate la migrazione gli utenti possono continuare aa operare e la durata della migrazione è correlata alla replica di AD in quanto la SYSVOL DFSR avviene durante una schedulazione della replica AD, questo significa che la DFRS legge e scrive gli stati ogni 5 min su ogni Domain Controller. Quindi la migrazione può impiegare pochi minuti in piccoli domini, ma alcune ore o giorni in domini estesi.

Per consentire la diagnostica del DFS è consigliabile installare il tool DFS Management la funzionalità Remote Server Administration ToolsFeature Administration ToolsRole Administration ToolsFile Services ToolsDFS Management Tools.

Per maggiori informazioni si veda SYSVOL Replication Migration Guide: FRS to DFS Replication e i seguenti post dello Storage Team:

Per le novità introdotte nella replica DFS in Windows Server 2012 si veda DFS Replication Improvements in Windows Server 2012, mentre in Windows Server 2016 e Windows 10, come indicato in What’s New in File and Storage Services in Windows Server 2016 Technical Preview, è stato implementato un hardening dell’SMB per le connessioni a SYSVOL e NETLOGON su Domain Controller richiedendo l’SMB signing e la mutua autenticazione, come ad esempio Kerberos, per ridurre la probabilità di attacchi man-in-the-middle (per maggiori informazioni si vedano la KB3000483 – MS15-011: Vulnerability in Group Policy could allow remote code execution: February 10, 2015 e il post MS15-011 & MS15-014: Hardening Group Policy).

Verifica dei prerequisiti e della funzionalità della replica FRS

Per verificare che la replica FRS funzioni correttamente è possibile eseguire i seguenti controlli:

  1. Verificare la funzionalità delle share NETLOGON e SYSVOL su ogni Domain Controller mediante i comandi:
    1. net share
    2. dcdiag /test:frssysvol
    3. dcdiag /test:netlogons
    4. dcdiag /e /test:sysvolcheck /test:advertising
  2. Verificare su ogni Domain Controller che il volume su cui risiede la share SYSVOL abbia almeno lo spazio necessario pari alla dimensione della SYSVOL più 10%.
  3. Controllare la funzionalità della replica FRS tramite il tool FRSDIAG (si vedano le indicazioni nel seguente Verifying File Replication during the Windows Server 2008 DFSR SYSVOL Migration – Down and Dirty Style)
  4. Verificare su ogni Domain Controller (nell’esempio esiste solo VMDC2016) che la replica Active Directory funzioni correttamente tramite il comando repadmin /ReplSum.
  5. Verificare su ogni Domain Controller che la chiave di registro HKLM\System\CurrentControlSet\Services\Netlogon\Parameters contenga il valore SysVol impostato a [drive:\]Windows_folder\SYSVOL\sysvol e che contenga il valore SysvolReady impostato a 1.
  6. Controllare che su ogni Domain Controller il servizio Replica DFS (DFSR) sia avviato e impostato per l’avvio automatico.
  7. Il built-in Administrators group deve avere i privilegi di “Manage Auditing and Security Log” su tutti i Domain Controller, come da impostazione di default (a rigaurdo si veda la KB2567421 DFSR SYSVOL Fails to Migrate or Replicate, SYSVOL not shared, Event IDs 8028 or 6016).

Per poter utilizzare la replica DFS occorre aumentare il livello funzionale portandolo almeno a Windows Server 2008, ma se si suppone di inserire nell’infrastruttura solo Domain Controller Windows Server 2016 o superiori conviene portare a Windows Server 2016 il livello funzionale della foresta per beneficiare di tutte le novità introdotte. E’ possibile elevare il livello funzionale del dominio e della foresta tramite il tool i Servizi di dominio di Active Directory come visto precedentemente oppure usare i seguenti comandi PowerShell:

#Raise livello funzionale del dominio a Windows 2016
Set-ADDomainMode -Identity devadmin.local -DomainMode Windows2016

#Verifica livello funzionale del dominio corrente
(Get-ADDomain).DomainMode

#Raise livello funzionale della foresta a Windows 2016
Set-ADForestMode -Identity devadmin.local -ForestMode Windows2016

#Verifica del livello funzionale della foresta corrente
(Get-ADForest).ForestMode

Per verificare che l’aumento del livello funzionale di dominio sia avvenuto correttamente è possibile controllare che sia stato registrato il seguente evento:

  • Registro Directory Services – Evento d’informazioni ActiveDirectory_DomainService 2039

Per verificare che l’aumento del livello funzionale della foresta sia avvenuto correttamente è possibile controllare che sia stato registrato il seguente evento:

  • Registro Directory Services – Evento d’informazioni ActiveDirectory_DomainService 2040

Migrazione del dominio nello stato Prepared

Prima di eseguire la migrazione del dominio nello stato Prepared eseguire un backup del system state dei Domain Controller nell’infrastruttura (nell’esempio esiste solo VMDC2016). Terminato il backup dei system state dei Domain Controller nell’infrastruttura, che consentirà di rispristinare la situazione precedente nel caso subentrassero problemi, è possibile impostare il global migration state a Prepared eseguendo da un Domain Controller (preferibilmente il PDC Emulator e comunque non un Read Only Domain Controller) il comando:

dfsrmig /setglobalstate 1

Per verificare che il global migration state è stato impostato a Prepared è possibile utilizzare il seguente comando:

dfsrmig /getglobalstate

Per verificare che tutti i Domain Controller abbiano raggiunto lo stato Prepared è possibile utilizzare il seguente comando:

dfsrmig /getmigrationstate

Per verificare che il global migration state è stato impostato a Prepared è possibile controllare che sia stato registrato il seguente evento:

  • Registro DFS Replication – Evento d’informazioni DFSR 8014

Verificare che su ogni Domain Controller sia stata creata la directory %SystemRoot%\SYSVOL_DFSR e che il contenuto delle directory domain e sysvol in %SystemRoot%\SYSVOL sia stato copiato in %SystemRoot%\SYSVOL_DFSR.

Utilizzate il tool DFS Management per creare un report diagnostico per la directory SYSVOL_DFSR tramite la seguente procedura:

  1. Selezionare il nodo Replication – Domain System Volume
  2. Verificare nel Tab Memeberships che per tutti i Domain Controller sia abilitata la replica per il path %SystemRoot%\SYSVOL_DFSR\domain.
  3. Selezionare Actions – Create Diagnostics Report.
  4. Creare un Health report, un
    Propagation test e un Propagation report verificando che non vi siano errori.

Nello stato di Prepared FRS e DFSR hanno le proprie copie della SYSVOL, le shares SYSVOL e Netlogon si referenziano alla copia FRS, ma è ancora possibile eseguire il rollback tramite il comando:

dfsrmig /setglobalstate 0

Migrazione del dominio nello stato Redirect

Per impostare il global migration state a Redirect eseguire da un Domain Controller (preferibilmente il PDC Emulator e comunque non un Read Only Domain Controller) il comando:

dfsrmig /setglobalstate 2

Per verificare che il global migration state è stato impostato a Redirect è possibile utilizzare il seguente comando:

dfsrmig /getglobalstate

Per verificare che tutti i Domain Controller hanno raggiunto lo stato Redirect è possibile utilizzare il seguente comando:

dfsrmig /getmigrationstate

Per verificare che il global migration state è stato impostato a Redirect è possibile controllare che sia stato registrato il seguente evento:

  • Registro Replica DFS – Evento d’informazioni DFSR 8017

Verificare su ogni Domain Controller tramite il comando net share che le share NETLOGON e SYSVOL mappino rispettivamente le directory:

  • %SystemRoot%\SYSVOL_DFSR\sysvol\NomeDominioDNS\SCRIPTS
    (nell’esempio C:\Windows \ SYSVOL_DFSR\sysvol\devadmin.local\SCRIPTS)
  • %SystemRoot%\SYSVOL_DFSR\sysvol

Usare il tool DFS Management per creare un report diagnostico per la directory SYSVOL_DFSR utilizzando la procedura descritta precedentemente.

Controllare la funzionalità della replica FRS tramite il tool FRSDIAG (si vedano le indicazioni nel seguente Verifying File Replication during the Windows Server 2008 DFSR SYSVOL Migration – Down and Dirty Style). La replica FRS deve continuare ad essere funzionante per garantire la possibilità di un eventuale roll back.

Nello stato di Redirect FRS e DFSR hanno le proprie copie della SYSVOL e le shares SYSVOL e Netlogon si referenziano alla copia DFS, ma è ancora possibile eseguire il rollback allo stato di Prepared tramite il comando:

dfsrmig /setglobalstate 1

oppure è possibile eseguire il rollback allo stato iniziale tramite il comando:

dfsrmig /setglobalstate 0

Migrazione del dominio nello stato Eliminated

Prima di eseguire la migrazione del dominio nello stato Eliminated eseguire le seguenti operazioni:

  1. Verificare tramite il comando repadmin /ReplSum che la replica di Active Directory funzioni correttamente.
  2. Eseguire un backup del system state dei Domain Controller nell’infrastruttura che consentirà di rispristinare la situazione precedente nel caso subentrassero problemi.

Per impostare il global migration state a Eliminated eseguire da un Domain Controller (preferibilmente il PDC Emulator e comunque non un Read Only Domain Controller) il comando:

dfsrmig /setglobalstate 3

Per verificare che il global migration state è stato impostato a Eliminated è possibile utilizzare il seguente comando:

dfsrmig /getglobalstate

Per verificare che tutti i Domain Controller hanno raggiunto lo stato Eliminated è possibile utilizzare il seguente comando:

dfsrmig /getmigrationstate

Per verificare che il global migration state è stato impostato a Eliminated è possibile controllare che sia stato registrato il seguente evento:

  • Registro Replica DFS – Evento d’informazioni DFSR 8019

Verificare su ogni Domain Controller tramite il comando net share che le share NETLOGON e SYSVOL mappino rispettivamente le directory:

  • %SystemRoot%\SYSVOL_DFSR\sysvol\NomeDominioDNS\SCRIPTS
    (nell’esempio C:\Windows \ SYSVOL_DFSR\sysvol\devadmin.local\SCRIPTS)
  • %SystemRoot%\SYSVOL_DFSR\sysvol

Usare il tool DFS Management per creare un report diagnostico per la directory SYSVOL_DFSR utilizzando la procedura descritta precedentemente.

Verificare che su ogni Domain Controller sia stata rimossa la directory % SystemRoot%\SYSVOL.

Arrestare e disabilitare il servizio FRS su tutti Domain Controller, tranne nel caso in cui l’FRS venisse utilizzato per repliche diverse dalla directory SYSVOL. E’ possibile eseguire tale configurazione tramite i comandi:

sc stop ntfrs
sc config ntfrs start=disabled

Per ulteriori informazioni sulla procedura di migrazione si vedano i post sul blog del team di Directory Services:

Conclusioni

La migrazione della replica SYSVOL da FRS a DFS è un’operazione caldamente consigliata dal momento che con Windows Server 2016 l’File Replication Service (FRS) e i livelli funzionali Windows Server 2003 sono deprecati. Inoltre una volta dismessi controller di dominio Windows Server 2003 per avere nell’infrastruttura solo controller di dominio Windows Server 2008 non vi è più alcuna ragione di utilizzare l’FRS per la replica della SYSVOL dal momento che il DFS, come spiegato precedentemente, offre maggiori prestazioni e robustezza.

Individuare il modello corretto di Cloud

Facebooktwittergoogle_plusredditlinkedin

Quando si tratta di risorse di calcolo, le aziende sono in genere in una delle due categorie: quelli che hanno già approfittato del Cloud e quelli che si avvarranno del Cloud in un prossimo futuro. Te da che parte stai ? Per entrambe le categorie, sapere quali risorse  migrare  e come effettuare la migrazione è

Backup in Cloud: una opportunità da non perdere

Facebooktwittergoogle_plusredditlinkedin

Alzi la mano chi non sa cosa sia un Backup, probabilmente la funzionalità più ‘vecchia’ nel mondo IT nata un minuto dopo che il primo documento o sorgente di un programma è stato inavvertitamente cancellato. Alzi sempre la mano chi non ha MAI perso un documento, per qualsiasi ragione: dalla cancellazione involontaria, alla sovrascrittura, allo

Cloud System Integrator. Cos’è e cosa fa?

Facebooktwittergoogle_plusredditlinkedin

La domanda sorge spontanea : cosa e’ e cosa fa un Cloud System Integrator ? Ma sopratutto : a chi serve ? Se anche te ti stai facendo queste domande allora sei arrivato nel post(o) giusto visto che siamo stati i primi in Italia ad intrapendere questa attività e ‘forgiare’ il termine Cloud System Integrator.