Considerazioni necessarie prima dell’utilizzo di Hyper-V Replica
La replica Hyper-V è una funzionalità che è parte integrante del ruolo Hyper-V pensata per favorire una strategia di ripristino di emergenza replicando le macchine virtuali da un server host Hyper-V ad un altro. Prima di valutarle l’utilizzo occorre analizzare attentamente le caratteristiche per essere certi che tale funzionalità sia adatta a realizzare lo scenario di ripristino di emergenza che si intende implementare.
Come indicato in Set up Hyper-V Replica | Microsoft Learn il primo aspetto di cui tenere in conto è che quando si configura la replica nel server host secondario viene creata una copia della macchina virtuale tramite la replica iniziale, ma successivamente vengono replicate solo le modifica ai dischi virtuali via HTTP o HTTPS, questo significa che ogni modica eseguita alla configurazione della macchina virtuale eseguita dopo la prima replica non verrà replicata sulla macchina virtuale nell’host secondario.
When you enable Hyper-V Replica for a specific virtual machine, initial replication creates an identical replica virtual machine on a secondary host server. After that happens, Hyper-V Replica change tracking creates and maintains a log file that captures changes on a virtual machine VHD. The log file is played in reverse order to the replica VHD based on replication frequency settings. This means that the latest changes are stored and replicated asynchronously. Replication can be over HTTP or HTTPS.
Quando si verifica un’interruzione di servizio nell’infrastruttura sorgente della replica o nel canale di comunicazione è possibile è possibile avviare manualmente un failover di test, pianificato o non pianificato, ma occorre tenere presente che per tale operazione vengono fornite indicazioni specifiche a cui attenersi (a riguardo si veda Set up Hyper-V Replica | Microsoft Learn):
| Question | Test | Planned | Unplanned |
| When should I run this? | Verify that a virtual machine can fail over and start in the secondary site Useful for testing and training |
During planned downtime and outages | During unexpected events |
| How often should I run? | We recommend once a month for testing | Once every six months or in accordance with compliance requirements | Only in case of disaster when the primary virtual machine is unavailable |
| Does the primary virtual machine continue to replicate? | Yes | Yes. When the outage is resolve reverse replication replicates the changes back to the primary site so that primary and secondary are synchronized. | No |
| Is there any data loss? |
None | None. After failover Hyper-V Replica replicates the last set of tracked changes back to the primary to ensure zero data loss. | Depends on the event and recovery points |
| Is a duplicate virtual machine created? |
Yes | No | No |
| Is there any downtime? | None. It doesn’t impact your production environment. It creates a duplicate test virtual machine during failover. After failover finishes you select Failover on the replica virtual machine and it’s automatically cleaned up and deleted. | The duration of the planned outage | The duration of the unplanned outage |
Un altro aspetto da tenere presente, come indicato in Set up Hyper-V Replica | Microsoft Learn, è che la Replica di Hyper-V mantiene la coerenza dello stato del sistema operativo della macchina virtuale dopo un failover, ma non la coerenza dello stato delle applicazioni in esecuzione nella macchina virtuale. Per recuperare le applicazioni in uno stato coerente occorre creare avere la coerenza dello stato delle applicazioni è necessario creare punti di ripristino i cui le applicazioni sono coerenti:
Figure out which workloads you’ll replicate: Standard Hyper-V Replica replication maintains consistency in the state of the virtual machine operating system after a failover, but not the state of applications that running on the virtual machine. If you want to be able to recovery your workload state you can create app-consistent recovery points. Note that app-consistent recovery isn’t available on the extended replica site if you’re using extended (chained) replication.
Per creare punti di ripristino in cui le applicazioni sono coerenti è necessario disporre di VSS writers specificatamente pensati per l’applicazione e abilitare l’opzione Configura i punti di ripristino aggiuntive (si tenga presente che nella macchina virtuale dovranno essere presenti gli Integration Components e che nei sistemi operativi non Windows verranno creati snapshot consistenti a livello di file):
On the Configure Additional Recovery Points page, select whether you want to maintain only the latest recovery point or to create additional points. If you want to consistently recover applications and workloads that have their own VSS writers we recommend you select Volume Shadow Copy Service (VSS) frequency and specify how often to create app-consistent snapshots. Note that the Hyper-V VMM Requestor Service must be running on both the primary and secondary Hyper-V servers. Then click Next.
Nel caso si voglia utilizzare Hyper-V Replica per replicare Domain Controller virtuali è necessario che tali Domain Controller siano in esecuzione in Windows Server 2012 o successivo in quanto è necessario che si disponga della funzionalità VM-GenerationID (VMGenID), a riguardo si vedano:
- Support for using Hyper-V Replica for virtualized domain controllers | Microsoft Learn
- Virtual Active Directory Domain Services Domain Controllers Hyper-V | Microsoft Learn
Per una guida sull’implementazione di Hyper-V Replica si veda Hyper-V Replica: come configurare la replica delle macchine virtuali in Hyper-V con autenticazione basata su certificati – ICT Power.