Archivi categoria: Windows Server

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.

Please follow and like us:

Come affrontare la fine del ciclo di vita di Windows Server 2008\2008 R2

La fine del supporto Microsoft per i sistemi operativi Windows Server 2008 e Windows Server 2008 R2 è imminente e prevista per il 14 gennaio 2020. A partire da questa data Microsoft non rilascerà più update di security in modo gratuito per queste piattaforme in ambiente on-premises. Purtroppo, sono ancora molti i sistemi in ambiente di produzione che adottano queste versioni di sistema operativo. In questo articolo vengono affrontati gli approcci che è possibile adottare per affrontare questa situazione, evitando di esporre la propria infrastruttura a problematiche di security causate dall’indisponibilità degli aggiornamenti necessari.

La fine del periodo extended support per queste piattaforme implica che Microsoft, a meno che non vengano svolte determinate azioni, non rilascerà più i relativi security update. In queste condizioni l’esposizione ad attacchi di security è notevole e comporterebbe lo stato di non compliance rispetto a specifici regolamenti, come ad esempio il General Data Protection Regulation (GDPR). Questa condizione, sicuramente poco piacevole per chi si ritrova ad affrontarla ora, visti i tempi ristretti, può anche essere vista come una importante opportunità di rinnovo e innovazione della propria infrastruttura.

Per continuare a ricevere gli update di security per i sistemi Windows Server 20082008 R2 ospitati in ambiente on-premises, l’unica possibilità è quella di aderire al programma Extended Security Update (ESU). Tale programma a pagamento è disponibile solo per i clienti in Software Assurance e garantisce il provisioning di Update di Security classificati come “critical” e “important” per ulteriori tre anni, a partire dal 14 gennaio 2020.

Qualora il programma ESU non lo si ritenga adeguato alle proprie esigenze si possono valutare due percorsi di upgrade totalmente differenti.

Upgrade on-premises

Questo percorso prevede il passaggio a una nuova versione di Windows Server in ambiente on-premises. Il consiglio in questo caso è di approcciare come piattaforma almeno Windows Server 2016 e di non procedere, qualora possibile, con aggiornamenti in place del sistema operativo, ma di gestire la migrazione in side-by-side. Questo metodo solitamente richiede un coinvolgimento del fornitore applicativo, per garantire la compatibilità software con la nuova versione del sistema operativo. Trattandosi di software non recenti, spesso viene richiesta l’adozione di versioni aggiornate degli stessi, che possono prevedere un adeguamento dell’architettura e una fase approfondita di test della nuova release. Adottando questo processo di upgrade i tempi e l’effort sono considerevoli, ma il risultato che si ottiene è fondamentale per rispettare il rinnovo tecnologico.

Migrazione verso Azure

Migrando i sistemi Windows Server 2008 e Windows Server 2008 R2 presenti on-premises in ambiente Azure si continueranno a ricevere per altri tre anni i security update, classificati come critici e importanti, senza dover aderire al programma ESU. Questo scenario non solo è utile per garantire il rispetto della compliance dei propri sistemi, ma apre la strada verso architetture ibride dove sarà possibile ottenere i vantaggi dati dal cloud. A questo proposito Microsoft offre un’ottima soluzione in grado di fornire un ampio set di strumenti necessari per affrontare al meglio i più comuni scenari di migrazione: Azure Migrate,  che struttura il processo di migrazioni in fase differenti (discovery, assessment, e migrazione). Questo approccio può risultare più immediato rispetto all’upgrade dei sistemi e consente di avere più tempo a disposizione per affrontare il rinnovo software. A questo proposito il cloud consente di avere un’ottima flessibilità e agilità nel testare gli applicativi in ambienti paralleli. Prima di iniziare il percorso di migrazione verso Azure è fondamentale strutturare il networking dell’ambiente ibrido in modo opportuno e valutare le iterazioni con gli altri componenti dell’infrastruttura, per constatare se l’applicativo può funzionare bene anche in ambiente cloud.

Indipendentemente dal percorso di upgrade che si decide adottare il consiglio è di fare un assessment dettagliato, in modo da poter categorizzare ciasun workload per tipologia, criticità, complessità e rischio. In questo modo è possibile dare delle priorità e procedere con un piano strutturato di migrazione.

Conclusioni

Per tutti coloro che all’interno del proprio datacenter dispongono di sistemi Windows Server 2008 oppure Windows Server 2008 R2 è opportuno gestire la condizione che Microsoft a breve non rilascerà più update di security in modo gratuito, esponendo così i sistemi a potenziali problemi di sicurezza. Allo stesso tempo sono diverse le possibilità offerte da Microsoft per affrontare nel migliore dei modi questa situazione. Il percorso di migrazione verso Azure è sicuramente un’opzione molto interessante che consente di iniziare il percorso per espandere il proprio datacenter nel cloud pubblico di Microsoft.

Please follow and like us: