Hyper-V Replica: replica asincrona a livello di host

Hyper-V Replica replica in modo asincrono una singola VM da un host primario a un host replica, indipendente dallo storage sottostante. È la distinzione più importante dell’esame: non richiede né shared storage né un failover cluster, i due host possono trovarsi in siti geografici diversi e non devono condividere nulla. La frequenza di replica è configurabile su 30 secondi, 5 minuti o 15 minuti: questo valore determina di fatto il tuo RPO. L’autenticazione avviene via Kerberos (HTTP) oppure tramite certificati (HTTPS) quando il traffico attraversa reti non fidate. Puoi conservare recovery point aggiuntivi e snapshot application-consistent generati tramite VSS, utili per workload transazionali. Con la extended (chained) replication propaghi la replica a un terzo host in un sito ulteriore: ad esempio primario in sede, replica in filiale, extended replica in un data center remoto.

Failover pianificato, non pianificato e di test

Tre operazioni distinte, che l’esame ama confondere. Il test failover crea una copia isolata della VM replica in una rete separata, senza fermare la replica in corso né toccare la produzione: serve a validare il piano di DR. Il planned failover si avvia dal sito primario, richiede lo spegnimento della VM sorgente e garantisce zero perdita di dati, perché replica le modifiche residue prima di invertire la direzione; è la scelta per manutenzioni programmate o migrazioni ordinate. Il failover non pianificato si avvia invece dal sito replica quando il primario è già perso: recupera l’ultimo recovery point disponibile e comporta una possibile perdita di dati pari all’intervallo di replica. Ripristinato il sito primario, si esegue la reverse replication per riallineare prima di rientrare.

Azure Site Recovery e l’orchestrazione del DR

Hyper-V Replica copre lo scenario Hyper-V verso Hyper-V con failover manuale, una VM alla volta. Azure Site Recovery (ASR) è il servizio di DRaaS che orchestra la protezione di workload on-prem (Hyper-V, VMware, server fisici) verso Azure, oppure di VM Azure da una region all’altra, appoggiandosi a un Recovery Services vault. Il valore aggiunto sono i recovery plan: raggruppano più VM, ne definiscono l’ordine di avvio, iniettano script e runbook di Azure Automation e prevedono azioni manuali, così da riavviare un’applicazione multi-tier nella sequenza corretta (prima il database, poi l’application server, infine il front-end). ASR supporta test failover, planned failover (senza perdita di dati, per gli scenari on-prem) e unplanned failover, oltre al failback verso il sito di origine. Scegli ASR quando serve Azure come sito di DR, un failover coordinato di molti workload o audit di conformità sulle prove di DR; resta su Hyper-V Replica quando hai due sedi con host Hyper-V e un requisito semplice.

RTO e RPO: dimensionare il piano

Il RPO (Recovery Point Objective) è la massima perdita di dati accettabile, misurata nel tempo: lo governi con la frequenza di replica. Il RTO (Recovery Time Objective) è il massimo downtime tollerato: dipende da quanto rapidamente porti online i workload, ed è qui che i recovery plan di ASR fanno la differenza rispetto al failover manuale. Un RPO stringente impone replica frequente e più banda; un RTO stringente impone automazione e orchestrazione. Le domande d’esame partono quasi sempre da questi due numeri per farti scegliere la tecnologia; ricorda che si supera con un passing score di 700/1000.

Trappole tipiche d’esame

  • Serve alta disponibilità con failover automatico e zero downtime → soluzione: failover cluster con shared storage, non Hyper-V Replica; Replica è DR asincrono con failover manuale ed eventuale perdita di dati, non HA.
  • Requisito di RPO più basso possibile → soluzione: imposta la frequenza di replica a 30 secondi in Hyper-V Replica; è la frequenza a determinare l’RPO, non il numero di recovery point conservati.
  • Validare il piano di DR senza impattare la produzione → soluzione: test failover in rete isolata; il planned failover invece spegne la VM sorgente e interrompe il servizio.
  • Failover garantito senza perdita di dati per una manutenzione → soluzione: planned failover dal primario; l’unplanned failover dal replica può perdere fino a un intervallo di replica.
  • DR di un’app multi-tier con avvio ordinato verso Azure → soluzione: recovery plan di ASR con gruppi e runbook; Hyper-V Replica da solo non orchestra l’ordine di boot di più VM.
  • DR verso Azure di VMware o server fisici → soluzione: Azure Site Recovery, non Hyper-V Replica, che replica soltanto tra host Hyper-V.