Archivi categoria: Storage

Soluzioni di Disaster Recovery: Storage Replica vs DFS Replication

Microsoft Storage Replica è una tecnologia introdotta a partire da Windows Server 2016 che tra i principali scenari di utilizzo prevede la replica di volumi, in modo sincrono oppure asincrono, tra server o cluster, a fini di disaster recovery. Al giorno d’oggi diversi clienti Microsoft continuano ad utilizzare DFS Replication (DFS-r) come soluzione di Disaster Recovery per i dati non strutturati come home folders e share dipartimentali. Il quesito che molti si pongono è se la recente tecnologia Storage Replica prende davvero il posto dell’ormai consolidato meccanismo DFS-r. In questo articolo saranno approfondite le caratteristiche delle due soluzioni in modo da chiarire quando conviene utilizzare Storage Replica e quando DFS Replication (DFS-r).

DFS Replication (DFS-r)

DFS Replication è una soluzione attivabile tramite un ruolo presente in Windows Server che consente di replicare le cartelle su differenti server e siti geografici. La soluzione è basata su un efficiente motore di replica, che contempla la presenza di più master, il quale è possibile utilizzarlo per mantenere le cartelle sincronizzate tra differenti server, anche attraverso connessioni di rete con larghezza di banda limitata. DFS-r utilizza un algoritmo di compressione noto come Remote Differential Compression (RDC), in grado di rilevare le modifiche di un file e di replicare solo i blocchi modificati anziché l’intero file. Ormai da tempo DFS-r ha sostituito il servizio File Replication Service (FRS) ed è anche utilizzato per la replica della cartella SYSVOL di Active Directory Domain Services (AD DS) nei domini dove il functional level è almeno Windows Server 2008.

L’attivazione di DFS-r prevede la creazione di gruppi di replica che contengono i file e le cartelle da replicare:

Figura 1 – Processo di replica di DFS-r

Per maggiori informazioni sul servizio DFS Replication (DFS-r) è possibile consultare la relativa documentazione Microsoft.

Storage Replica

Storage Replica è una tecnologia introdotta a partire da Windows Server 2016 e consente la replica di volumi tra server o cluster a fini di Disaster Recovery.

Figura 2 – Scenari di replica storage Server-to-server e Cluster-to-cluster

Questa tecnologia consente inoltre di realizzare dei stretch failover cluster con nodi dislocati su due site differenti, mantenendo lo storage sincronizzato.

Figura 3 – Scenari di replica storage in stretch cluster

In Windows Server 2016 la possibilità di utilizzare Storage Replica c’è solamente se si utilizza la versione Datacenter Edition del sistema operativo, mentre in Windows Server 2019 c’è la possibilità di attivare Storage Replica anche adottando la Standard Edition, ma con le seguenti limitazioni:

Sarà possibile replicare un singolo volume anziché un numero illimitato di volumi.
La dimensione massima del volume replicato non dovrà superare i 2 TB.

Per maggiori informazioni su Storage Replica è possibile consultare la relativa documentazione Microsoft.

Confronto tra le soluzioni

La soluzione DFS-r risulta particolarmente efficace in ambienti con una banda di rete limitata e dove è necessario replicare su differenti nodi dei contenuti per i quali sono previste un numero limitato di modifiche. Tuttavia, DFS-r presenta notevoli limiti come soluzione di replica dei dati, tra i quali:

Non è in grado di replicare file in uso oppure aperti.
Non prevede un meccanismo di replica sincrona.
La latenza per la replica asincrona può essere di durata considerevole (minuti, ore o persino giorni).
Si basa su un database che può richiedere controlli di consistenza onerosi in seguito ad eventuali interruzioni del sistema.
L’onere di gestione dell’ambiente è elevato.

La soluzione Storage Replica non presenta le limitazioni sopra elencate, ma è bene tenere in considerazione i seguenti aspetti che la differenziano dalla soluzione DFS-r e che in alcuni scenari potrebbero essere considerati come elementi di criticità:

La replica avviene a livello di volume ed è consentita solo la replica uno a uno tra i volumi. Risulta comunque possibile replicare diversi volumi tra più server.
Consente di replicare in modo sincrono oppure asincrono, ma non è progettata per reti con larghezza di banda ridotta e latenza elevata.
Non è consentito l’accesso degli utenti ai dati protetti sul server di destinazione mentre la replica è in corso.
- Per validare l’efficacia del processo di replica è comunque possibile effettuare un Test Failover, che consente di effettuare il mount di una writable snapshot dello storage replicato. Per poter compiere questa operazione, a fini di test o backup, è necessario disporre di un volume, non coinvolto nel processo di replica, sul server di destinazione. Il Test Failover non ha impatto sul processo di replica, il quale continuerà a garantire la protezione del dato e le modifiche apportate alla snapshot rimarranno circoscritte al volume di test.

Come sostituire DFS Replication (DFS-r) con Storage Replica?

Se le caratteristiche di Storage Replica non vengono considerati bloccanti, questa più recente tecnologia è possibile adottarla per sostituire la soluzione DFS Replication (DFS-r). Il processo ad alto livello prevede i seguenti passaggi:

Installare i nuovi sistemi almeno Windows Server 2016, facendo attenzione a valutare i limiti imposti dalla Standard Edition, e configurare lo storage. Per approfondire i miglioramenti introdotti in ambito Storage Replica con Windows Server 2019 è possibile consultare questo articolo.
Migrare i dati che si desidera replicare su uno o più volumi di dati (ad esempio tramite Robocopy).
Abilitare la replica di Storage Replica e completare la sincronizzazione iniziale.
Si consiglia di abilitare le snapshot tramite Volume Shadow Copies, in particolare nel caso di replica asincrona. Le snapshots vengono anch’esse replicate insieme ai file. In caso di emergenza, sarà così possibile ripristinare i file dagli snapshot sul server di destinazione che potrebbero essere stati replicati solo parzialmente in modo asincrono.
Condividere i dati presenti sul server di origine e renderli accessibili tramite un DFS namespace. Questo aspetto è importante per garantire che gli utenti possano comunque accedere ai dati nel momento in cui cambia il nome del server durante l’attivazione del piano di Disaster Recovery. Sul server target della replica (sito di DR) è possibile creare le share (non accessibili durante le normali operazioni). Il server sul sito di DR potrà essere aggiunto al DFS Namespaces mantenendo le folder target disabilitate.

Nel caso risulti necessario attivare lo scenario di Disaster Recovery, utilizzando la soluzione Storage Replica, è opportuno procedere nel modo seguente:

Rendere principale il server dislocato nel site di DR, in modo che sia in grado di mostrare i volumi replicati agli utenti.
In caso di replica sincrona, non sarà necessario alcun ripristino dei dati, a meno che durante la perdita del server di origine l’utente non stesse utilizzando un’applicazione che scriveva dati senza protezione delle transazioni.
In caso di replica asincrona, può essere necessario effettuare il mount di una snapshot per garantire la consistenza dei dati a livello applicativo.
Attivare le folder target nel DFS Namespaces per consentire agli utenti di accedere ai propri dati.

Conclusioni

Microsoft sta continuando ad effettuare importanti investimenti in ambito storage e Storage Replica è il risultato tangibile che permette ai clienti di adottare un efficace e performante soluzione di replica dello storage. In ambito Disaster Recovery sono diversi gli scenari dove Storage Replica può andare a sostituire il servizio DFS Replication (DFS-r), ma è opportuno valutare attentamente le caratteristiche di entrambe le soluzioni per scegliere quella più adatta al proprio scenario d’uso.

Azure storage: Disaster Recovery e funzionalità di failover

Microsoft ha recentemente annunciato una nuova funzionalità che consente, per gli Azure storage account geo-ridondati, di effettuare in modo pilotato il failover. Tale caratteristica aumenta le capacità di controllo su questa tipologia di storage account, consentendo di avere una maggiore flessibilità in scenari di Disaster Recovery. In questo articolo viene mostrato il principio di funzionamento e la procedura da seguire per utilizzare questa nuova funzionalità.

Tipologie di storage account

In Azure sono presenti diverse tipologie di storage account con caratteristiche di replica distinte, per ottenere differenti livelli di ridondanza. Nel caso si voglia mantenere il dato presente sugli storage account disponibile anche a fronte di malfunzionamenti di una intera region di Azure è necessario adottare gli storage account di tipologia geo-ridondati, tra i quali se ne distinguono due differenti tipologie:

Geo-redundant storage (GRS): il dato viene replicato in modo asincrono in due region geografiche di Azure, distanti centinaia di miglia tra di loro.
Read-access geo-redundant storage (RA-GRS): segue lo stesso principio di replica precedentemente descritto, ma con la caratteristica che l’endpoint secondario può essere acceduto per leggere i dati replicati.

Utilizzando queste tipologie di storage account vengono mantenute tre copie del dato nella region primaria di Azure, selezionata in fase di configurazione, e ulteriori tre copie asincrone del dato in un’altra region di Azure, seguendo il principio delle Azure Paired Regions.

Figura 1 – Normale funzionamento dello storage di tipologia GRS/RA-GRS

Per maggiori informazioni sulle differenti tipologie di storage account e le relative caratteristiche di ridondanza è possibile consultare la documentazione ufficiale Microsoft.

Caratteristiche del processo di failover dello storage account

Grazie a questa nuova funzionalità, l’amministratore ha la possibilità di avviare il processo di account failover deliberatamente, nel momento in cui lo ritiene opportuno. Il processo di failover effettua un aggiornamento del record DNS pubblico dello storage account, in questo modo le richieste vengono indirizzate verso l’endpoint dello storage account presente nella region secondaria.

Figura 2 – Processo di failover per uno storage di tipologia GRS/RA-GRS

Al termine del processo di failover lo storage account è configurato per essere di tipologia Locally redundant storage (LRS) ed è necessario procedere con la relativa configurazione per renderlo nuovamente geo-ridondato.

Un aspetto importante da tenere in considerazione, quando si decide di intraprendere un failover dello storage account, è che tale operazione può comportare una perdita di dati, in quanto la replica tra le due region di Azure avviene in modalità asincrona. A causa di questo aspetto, in caso di indisponibilità della region primaria, potrebbero non essere stati replicate verso la region secondaria tutte le modifiche. Per verificare questa condizione è possibile fare riferimento alla proprietà Last Sync Time che indica il momento nel quale viene garantito che il dato è stato correttamente replicato verso la region secondaria.

Procedura di failover dello storage account dal portale Azure

In seguito, viene riportata la procedura per effettuare il failover di uno storage account direttamente dal portale Azure.

Figura 3 – Avvio del processo di failover dello Storage account

Figura 4 – Conferma del processo di failover dello Storage account

La procedura per avviare il failover di uno storage account può essere svolta non solo dal portale Azure, ma anche tramite PowerShell, Azure CLI, oppure utilizzando le API delle risorse Azure Storage.

Come individuare le problematiche sugli storage account

Microsoft raccomanda che gli applicativi che utilizzano gli storage account siano progettati per sostenere possibili errori in fase di scrittura. In questo modo l’applicativo dovrebbe esporre eventuali fallimenti riscontrati nella scrittura, in modo da essere allertati sulla possibile indisponibilità nell’accedere allo storage in una determinata region. Questo consentirebbe di intraprendere le dovute azioni correttive, come ad esempio il failover dello storage account in modalità GRSRA-GRS.

In modo nativo la piattaforma, tramite il servizio Azure Service Health, fornisce indicazioni dettagliate nel caso dovessero verificarsi condizioni che influenzano il funzionamento dei propri servizi presenti in Azure, compreso lo storage. Grazie alla completa integrazione di Service Health in Azure Monitor, il quale detiene il motore di alerting di Azure, è possibile configurare degli Alerts specifici qualora ci siano problemi lato Azure, che impattano sul funzionamento delle risorse presenti sulle proprie subscription.

Figura 5 – Creazione Health alert nel servizio Service Health

Figura 6 – Rule di notifica di problemi sullo storage

La notifica avviene tramite Action Groups, in seguito alla quale è possibile valutare la reale esigenza di intraprendere il processo di failover dello storage account.

Conclusioni

Prima del rilascio di questa funzionalità, in presenza di storage account di tipologia GRS/RA-GRS, il failover doveva comunque essere pilotato dal personale Microsoft a fronte di un fault che impattasse lo storage di una intera region Azure. Grazie a questa funzionalità viene fornito all’amministratore la possibilità di pilotare a piacimento il failover, garantendo così un maggiore controllo sugli storage account. Al momento questa funzionalità è disponibile in preview e solamente per gli storage account creati in determinate region Azure. Come accade per diverse funzionalità Azure in preview è bene attendere il rilascio ufficiale prima di utilizzarla per workload in ambiente di produzione.

Azure File Sync: panoramica della soluzione

Il servizio Azure File Sync (AFS) permette di centralizzare le cartelle di rete della propria infrastruttura in Azure Files, consentendo di mantenere le caratteristiche tipiche di un file server on-premises, in termini di performance, compatibilità e flessibilità e allo stesso tempo di beneficiare delle potenzialità offerte dal cloud. In questo articolo verranno riportate le caratteristiche principali del servizio Azure File Sync e le procedure da seguire per effettuarne il deployment.

Figura 1 – Schema di overview di Azure File Sync

Azure File Sync è in grado di trasformare Windows Server in una “cache” per accedere rapidamente ai contenuti presenti su una determinata Azure file share. L’accesso locale ai propri dati può avvenire con qualsiasi protocollo disponibile in Windows Server, come SMB, NFS, e FTPS. Si ha la possibilità inoltre di disporre di più server “cache” dislocati in location geografiche differenti.

Queste le caratteristiche principali di Azure File Sync:

Multi-site sync: si ha la possibilità di effettuare la sincronizzazione tra differenti site, consentendo di accedere in scrittura agli stessi dati tra differenti Windows Servers ed Azure Files.
Cloud tiering: vengono mantenuti localmente solo i dati acceduti di recente.
Integrazione con Azure backup: viene a decadere la necessità di effettuare il backup dei dati on premises. La protezione dei contenuti è possibile farla tramite Azure Backup.
Disaster recovery: si ha la possibilità di effettuare in modo immediato il ripristino dei metadata dei file e di richiamare solamente i dati necessari, per velocizzare le operazioni di riattivazione del servizio in scenari di Disaster Recovery.
Accesso diretto all’ambiente cloud: è consentito accedere direttamente ai contenuti presenti sulla File Share da altre risorse Azure (IaaS e PaaS).

Requisiti

Per poter effettuare il deployment di Azure File Sync è necessario disporre dei seguenti requisiti:

Un Azure Storage Account, con una file share configurata in Azure Files, nella stessa region dove si vuole fare il deploy del servizio AFS. Per effettuare la creazione di uno storage account è possibile seguire l’articolo Create a storage account, mentre la procedura di creazione della file share è riportata in questo documento.

Un sistema Windows Server con sistema operativo Windows Server 2012 R2 o successivo, il quale dovrà avere:

PowerShell 5.1, che è incluso di default a partire da Windows Server 2016.
Moduli PowerShell AzureRM.
Agente Azure File Sync. Il setup di installazione dell’agente può essere scaricato a questo indirizzo. Nel caso si intenda utilizzare AFS in ambiente cluster è opportuno installare l’agente su tutti i nodi del cluster. A questo proposito è bene precisare che Windows Server Failover Clustering è supportato da Azure File Sync per deployment di tipologia “File Server for general use”. L’ambiente Failover Cluster non è invece supportato su “Scale-Out File Server for application data” (SOFS) oppure su Clustered Shared Volumes (CSVs).
Si consiglia di mantenere l’opzione “Internet Explorer Enhanced Security Configuration” disabilitata sia per gli Administrators che per gli Users.

Concetti e configurazione del servizio

Dopo aver verificato la presenza di questi requisiti l’attivazione di Azure File Sync richiede di procedere con la creazione del servizio Storage Sync:

Figura 2 – Creazione servizio Storage Sync

Si tratta della risorsa top-level per Azure File Sync, la quale funge da contenitore per le relazioni di sincronizzazione tra i differenti storage account e molteplici Sync Group. Il Sync Group definisce la topologia di sincronizzazione per un set di files. Gli endpoint che si trovano all’interno dello stesso Sync Group vengono mantenuti in sincronizzazione tra di loro.

Figura 3 – Creazione Sync Group

A questo punto è possibile procedere con la registrazione del server avviando l’agente Azure File Sync.

Figura 4 – Avvio del processo di Sign-in

Figura 5 – Selezione dei parametri di registrazione del server

Figura 6 – Conferma di registrazione dell’agente

Al termine della registrazione il server comparirà anche nella sezione “Registered servers” del portale Azure:

Figura 7 – Server registrati nel servizio Storage Sync

Conclusa la registrazione del server è opportuno inserire un Server Endpoint all’interno del Sync Group, il quale integra un volume oppure una folder specifica, con un Registered Server, creando una location per la sincronizzazione.

Figura 8 – Aggiunta di un Server Endpoint

Aggiungendo un Server Endpoint è possibile abilitare la funzionalità di Cloud tiering che consente di mantenere, localmente sulla cache della macchina Windows Server, i file acceduti più frequentemente, mentre tutti i restanti file vengono salvati in Azure sulla base di specifiche policy che è possibile configurare. Per maggiori informazioni relative alla funzionalità di Cloud Tiering è possibile consultare la documentazione ufficiale Microsoft. A questo proposito è opportuno specificare che al momento non c’è supporto tra Azure File Sync con abilitata la funzionalità di cloud tiering, e la deduplica del dato. Nel caso si desideri abilitare Windows Server Data Deduplication occorre mantenere disabilitata la funzionalità di cloud tiering.

Dopo aver aggiunto uno o più Server Endpoint è possibile consultare lo stato del Sync Group:

Figura 9 – Stato del Sync Group

Per ottenere dei deployment di successo di Azure File Sync è inoltre necessario verificare attentamente la compatibilità con le soluzioni antivirus e di backup che vengono utilizzate.

Azure File Sync e DFS Replication (DFS-R) sono due soluzioni per la replica del dato e possono funzionare anche in side-by-side purché siano rispettate queste condizioni:

Azure File Sync cloud tiering deve essere disabilitato sui volumi con cartelle DFS-R replicate.
I Server endpoints non devono essere configurati su cartelle DFS-R read-only.

Azure File Sync può essere un ottimo sostituto di DFS-R e per la migrazione è possibile seguire le indicazioni riportate in questo documento. Rimangono alcuni scenari specifici che possono richiedere l’utilizzo contemporaneo di entrambe le soluzioni di replica:

Non tutti i server on-premises che necessitano di una copia dei file possono essere connessi a Internet.
Quando i branch servers consolidano i dati in un singolo hub server, sul quale viene poi utilizzato Azure File Sync.
Durante la fase di migrazione di deployment di DFS-R verso Azure File Sync.

Conclusioni

Azure File Sync è una soluzione che consente di estendere il classico file server dislocato on-premises con nuove funzionalità di sincronizzazione dei contenuti, beneficando delle potenzialità del cloud pubblico di Microsoft in termini di scalabilità e flessibilità.

Storage Replica: le novità di Windows Server 2019 e la gestione con Windows Admin Center

Storage Replica, in casa Microsoft, è una tecnologia introdotta in Windows Server 2016 che consente di replicare, in modo sincrono oppure asincrono, volumi tra server o cluster, a fini di disaster recovery. Questa tecnologia consente inoltre di realizzare dei stretch failover cluster con nodi dislocati su due site differenti, mantenendo in sync lo storage. In questo articolo saranno presentate le novità, riguardanti Storage Replica, che verranno introdotte in Windows Server 2019 e verrà mostrato come attivare Storage Replica utilizzando il nuovo strumento di gestione Windows Admin Center.

Le novità di Storage Replica in Windows Server 2019

In Windows Server 2016 c’è la possibilità di utilizzare Storage Replica solamente se si utilizza la versione Datacenter Edition del sistema operativo, mentre in Windows Server 2019 ci sarà la possibilità di attivare Storage Replica anche adottando la Standard Edition, ma al momento con le seguenti limitazioni:

Sarà possibile replicare un singolo volume anziché un numero illimitato di volumi.
La dimensione massima del volume replicato non dovrà superare i 2 TB.
Il volume in replica potrà avere una sola partnership, invece che un numero illimitato di partners.

Grazie all’adozione di un nuovo formato di Log utilizzato da Storage Replica (Log v1.1), vengono introdotti importati miglioramenti di performance riguardanti il throughput e la latenza. Sarà possibile beneficiare di questi miglioramenti se tutti i sistemi coinvolti nel processo di replica saranno Windows Server 2019 e saranno in particolar modo evidenti su array all-flash e in cluster Storage Spaces Direct (S2D).

Per validare l’efficacia del processo di replica è stata introdotta la possibilità di effettuare un Test Failover. Attraverso questa nuova funzionalità è possibile effettuare il mount di una writable snapshot dello storage replicato. Per poter compiere questa operazione, a fini di test o backup, è necessario disporre di un volume, non coinvolto nel processo di replica, sul server di destinazione. Il Test Failover non ha impatto sul processo di replica, il quale continuerà a garantire la protezione del dato e le modifiche apportate alla snapshot rimarranno circoscritte al volume di test. Al termine dei test è opportuno effettuare un discard della snapshot.

Storage Replica in Windows Admin Center

Windows Admin Center, conosciuto anche con il nome di Project Honolulu, consente tramite una console web basata su HTML5, di gestire la propria infrastruttura in modo centralizzato.

Tramite Windows Admin Center è possibile installare sui server la feature Storage Replica e il relativo modulo PowerShell.

Figura 1 – Aggiunta della feature Storage Replica da Windows Admin Center

Figura 2 – Conferma installazione di Storage Replica e delle relative dipendenze

Figura 3 – Notifica dell’installazione avvenuta con successo

Al termine dell’installazione è richiesto un riavvio del server.

Giunti a questo punto è possibile configurare, tramite Windows Admin Center, una nuova partnership di replica. La stessa operazione potrebbe essere compiuta utilizzando il cmdlet Powershell New-SRPartnership.

Figura 4 – Aggiunta nuova partnership di Storage Replica tra due replication Group

Figura 5 – Impostazioni richieste per la configurazione della Partnership

Windows Admin Center riporta, al termine della configurazione, i dettagli della partnership.

Figura 6 – Dettagli della partnership di replica

Inoltre, è possibile gestire lo stato della replica (suspend \ resume), invertire la direzione della sincronizzazione e modificare le configurazioni (aggiunta \ rimozione dei volumi di replica e impostazioni della partnership).

Figura 7 – Switch della direzione della replica

Figura 8 – Modifica delle impostazioni della partnership di replica

Conclusioni

Windows Server 2019 introdurrà significativi cambiamenti nel servizio di Storage Replica che, oltre ad evolverlo in termini di performance ed efficacia, lo renderanno anche maggiormente accessibile. Il tutto viene arricchito dalla possibilità offerta da Windows Admin Center di gestire in modo semplice, rapido e completo anche Storage Replica. Microsoft sta facendo importanti investimenti in ambito storage e i risultati sono evidenti e tangibili. Per chi volesse testare in anteprima le novità di Windows Server 2019 può partecipare al programma Windows Insider.

Windows Server 2016: Introduzione agli Hyper-V VHD Set

In Windows Server 2016 una nuova e interessante funzionalità è stata introdotta in ambito Hyper-V ed è chiamata VHD Set. Si tratta di una nuova modalità di creazione dei dischi virtuali che necessitano di essere condivisi tra più macchine virtuali, utile per implementare guest cluster. In questo articolo verranno approfondite le caratteristiche dei VHD Set, verrà spiegato come implementarli al meglio e come affrontare in modo efficace scenari di migrazione.

Caratteristiche

La possibilità di condividere dischi virtuali tra più macchine virtuali è necessaria per realizzare configurazioni guest cluster che richiedono la presenza di storage condiviso e per evitare di dover configurare l’accesso allo storage tramite ad esempio HBA virtuali oppure attraverso l’utilizzo del protocollo di comunicazione iSCSI.

Figura 1 – VHD Set

In ambito Hyper-V questa funzionalità è stata introdotta con Windows Server 2012 R2 con la tecnologia chiamata Shared VHDX, la quale presenta i seguenti importanti limiti che spesso ne impediscono l’utilizzo in ambiente di produzione:

Il backup degli Shared VHDX deve avvenire con agenti specifici e non è supportato il backup host based
Non sono supportati scenari di replica Hyper-V
Il resize online di Shared VHDX non è contemplato

Con Hyper-V in Windows Server 2016 è stata rivoluzionata questa funzionalità con l’introduzione dei VHD Set al posto degli Shared VHDX che rimuove le limitazioni sopra elencate rendendola una tecnologia matura e affidabile anche per gli ambienti di produzione. Infatti le macchine virtuali configurate per accedere ai VHD Set è possibile proteggerle tramite backup host based, senza dover installare agenti sulle macchine guest. In questo caso è comunque consigliata una verifica per stabilire se la soluzione di backup in uso supporta questa configurazione. Inoltre i dischi nel formato VHD Set supportano il ridimensionamento online, senza la necessità di dover fermare il guest cluster configurato per accederci. Anche la replica Hyper-V supporta i dischi nel formato VHD Set consentendo di implementare scenari di disaster recovery anche per configurazioni guest cluster.

Al momento le uniche limitazioni nell’utilizzo dei VHD Set sono date dal mancato supporto per la creazione di checkpoint delle macchine virtuali che ci accedono e dall’impossibilità di effettuare delle storage live migration di macchine virtuali con VHD Set. L’obiettivo di Microsoft per il futuro è comunque di rendere le macchine virtuali configurate con VHD Set paritetiche a tutte le altre in termini di funzionalità.

Requisiti per l’utilizzo di VHD Set

Il formato VHD Set è supportato solamente per sistemi operativi guest Windows Server 2016. Inoltre per poter configurare guest cluster dove le macchine virtuali accedono a dischi virtuali condivisi è necessario rientrare in uno dei seguenti scenari:

Hyper-V failover cluster con tutti i file delle VMs, compresi i dischi nel formato VHD Set, che risiedono su un Cluster Shared Volumes (CSV).
Hyper-V failover cluster che ha come storage location per i VHD Set una share SMB 3.0 erogata da uno Scale Out File Server (SOFS).

Figura 2 – Scenari supportati per l’utilizzo di dischi virtuali condivisi

Come Creare VHD Set

La creazione di dischi virtuali nel formato VHD Set può essere fatta sia da interfaccia grafica (GUI) che tramite Powershell. Per crearli tramite GUI è sufficiente aprire Hyper-V Manager e dal riquadro Actions selezionare New, Hard Disk. Tra i possibili formati sarà presente anche VHD Set come mostrato nella figura seguente:

Figura 3 – Selezione del formato nel wizard di creazione dei dischi virtuali

Proseguendo con il Wizard è possibile specificare se il disco deve essere di tipologia Fixed piuttosto che Dynamic, il nome, la location e la relativa dimensione nel caso si scelga di creare un nuovo disco blank. La stessa operazione può essere svolta anche utilizzando il cmdlet Powershell New-VHD, specificando come estensione del disco virtuale la nuova estensione .vhds, come mostrato dall’esempio seguente:

Figura 4 – Esempio di creazione di un disco nel formato VHD Set utilizzando Powershell

La creazione del disco nel formato VHD Set comporta la creazione nel percorso specificato dei seguenti file:

Figura 5 – File generati dalla creazione di un disco nel formato VHD Set

Il file con estensione .avhdx contiene i dati e può essere fixed o dynamic in base alla scelta fatta durante la creazione, mentre il file .vhds contiene i metadati necessari per coordinare l’accesso dai differenti nodi del guest cluster.

Configurazione delle Macchine Virtuali con Dischi VHD Set

Per poter aggiungere i dischi nel formato VHD Set alle macchine virtuali è sufficiente modificare le proprietà delle stesse e configurare in modo opportuno il collegamento al controller SCSI:

Figura 6 – Aggiunta dello Shared Drive nelle proprietà della VM

Successivamente è necessario selezionare la location del file:

Figura 7 – Configurazione della location del drive condiviso

La stessa operazione sarà necessario svolgerla per tutte le macchine virtuali che costituiranno il guest cluster. In seguito alla configurazione dello storage condiviso, che comporta l’aggiunta alle macchine virtuali dei dischi nel formato VHS Set, è possibile proseguire con la configurazione dell’ambiente guest cluster secondo la procedura standard di creazione di un cluster descritta nella documentazione ufficiale Microsoft.

Conversione di Shared VHDX in VHD Set

In scenari di aggiornamento dell’infrastruttura Hyper-V da Windows Server 2012 R2 a Windows Server 2016, può capitare di dover affrontare la migrazione di Shared VHDX in VHD Set per poter usufruire di tutti i vantaggi apportati nella nuova tecnologia di condivisione dei dischi virtuali. Il passaggio a Windows Server 2016 non comporta nessun aggiornamento automatico degli Shared VHDX in VHD Set ed è comunque consentito continuare ad utilizzare i dischi condivisi nel formato Shared VHDX anche in Windows Server 2016. Per poter migrare gli Shared VHDX nel formato VHD Set è necessario seguire la seguente procedura manuale:

Spegnere tutte le macchine virtuali connesse allo Shared VHDX che si intende migrare.
Scollegare lo Shared VHDX da tutte le VMs tramite il cmdlet Powershell Remove-VMHardDiskDrive oppure utilizzando Hyper-V Manager.
Avviare la conversione dello Shared VHDX nel formato VHD Set tramite il cmdlet Powershell Convert-VHD
Collegare il disco appena convertito nel formato VHD Set a tutte le VMs utilizzando il cmdlet Powershell Add-VMHardDiskDrive oppure utilizzando Hyper-V Manager.
Accendere le macchine virtuali connesse al VHD Set.

Quando si utilizzano dischi nel formato VHD Set possono essere utili i seguenti cmdlet Powershell:

Get-VHDSet: utile per visualizzare diverse informazioni relative al disco nel formato VHD Set, compresa la lista di eventuali checkpoint.
Optimize-VHDSet: necessario per ottimizzare l’allocazione dello spazio utilizzato dal disco nel formato VHD Set.

Conclusioni

In Windows Server 2016 l’introduzione dei VHD Set in ambito Hyper-V consente di implementare in modo semplice architetture guest cluster senza dover utilizzare tecnologie di condivisione dello storage che richiedono configurazioni più laboriose e complesse. Inoltre sono state rimosse buona parte delle limitazioni riguardanti la metodologia di condivisione dei dischi virtuali, presenti nella precedente versione di Hyper-V, rendendo VHD Set una tecnologia matura, affidabile e di conseguenza utilizzabile anche in ambienti di produzione.