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:

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.

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

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.