Hyper-V standalone hosts with non-shared storage and replication for failover

Overview

When using Hyper-V standalone hosts with non-shared storage and replication for failover, you’re implementing a cold or warm disaster recovery approach, not a live failover cluster. This model suits smaller environments or remote offices without SANs. Here are best practices to ensure reliability, efficiency, and recoverability:

---

Architecture Best Practices

1. Use Hyper-V Replica

• Set up replication between two standalone hosts (primary and replica).
• Enable planned failover (for maintenance) and unplanned failover (for disaster recovery).
• Configure replica frequency based on your RPO needs (default: 5 minutes; also 30s and 15min available).
• If needed, use extended replication to a tertiary site.

2. Avoid Using Internal Disks

• Prefer dedicated physical disks (RAID-protected) or pass-through disks.
• For better reliability and portability, use VHDX files on NTFS/ReFS volumes with Storage Spaces or similar redundancy.

3. Use Fixed or Dynamically Expanding Disks

• Prefer fixed VHDX for high I/O workloads (more predictable performance).
• Use dynamically expanding VHDX for low/moderate IOPS VMs to save space.

---

Reliability and Recovery Best Practices

4. Automate Replica Failover

• Use PowerShell scripts to automate failover/failback.
• Integrate with Hyper-V Replica Broker (optional with failover clustering; in your case, manual scripting and orchestration are key).

5. Test Failovers Regularly

• Perform test failovers quarterly.
• Validate replica VMs boot, function, and revert cleanly.

6. Application-Consistent Snapshots

• If using VSS-aware apps (e.g., SQL, Exchange), enable application-consistent replication.
• Ensure Integration Services are up to date inside each VM.

---

Networking Best Practices

7. Use Identical Virtual Switch Names

• Match virtual switch names on both hosts to simplify VM replication and failover.
• Use MAC address spoofing and DHCP reservations if needed.

8. Plan for DNS Updates

• Automate or prepare scripts to update DNS records after failover.
• Use short TTLs on DNS records to allow fast propagation.

---

Operational Practices

9. Isolate Replica Traffic

• Use a dedicated NIC or VLAN for replication traffic to avoid contention with production workloads.
• Throttle bandwidth if needed via QoS or replication configuration.

10. Monitor Replication Health

• Monitor via Event Viewer, PowerShell, or System Center VMM.
• Automate alerts for replication failures or extended queue times.

11. Backups Still Matter

• Replication is not a replacement for backup. Use VSS-aware backups of VMs and store off-host.
• Ensure replicated VMs are excluded from backup jobs to avoid conflicts.

---

Maintenance and Lifecycle

12. Keep Hosts Patched

• Use Cluster-Aware Updating (CAU) if eventually clustering, or stagger manual updates.
• Validate patch compatibility with Hyper-V and replication roles.

13. Document Recovery Procedures

• Maintain a written/runbook-style DR plan, including:
• Planned vs. unplanned failover procedures
• Networking and DNS adjustments
• Data consistency expectations

---

Tools You Can Use

• PowerShell Cmdlets: Get-VMReplication, Start-VMFailover, Complete-VMFailover, etc.
• SCVMM (optional): For orchestration and monitoring.
• Storage Replica (if using Server Datacenter Edition): For block-level replication on top of Hyper-V Replica.