When I first heard about Hyper-V Replica for Windows Server 2012, I was immediately awe-struck. I thought, this technology was a perfect addition to Microsoft’s Hyper-V virtualization services. Until replication services were available, the only viable solution for ‘Disaster Recovery’ was backups or enterprise-grade clustering. Clustering isn’t even considered a backup solution or even a DR solution, but rather, it’s in a category called ‘High Availability’.
I’m no stranger to clustering. I’ve installed my share of them. However, the implementation is complex, expensive, and sometimes a cause of failure in and of itself. The moment you use clustering, you immediately limit those whom are technically savvy enough to manage it. In the right situations, clustering is exactly what you should use. But for many organizations, it’s overkill.
In a mid-sized environment, there needs to be another solution whereby a business can recover very quickly from a hardware failure without having to resort to backups. There are 3rd party solutions that provide backups products that can perform a virtual-booted in under the 15-minute mark. But in practice, I’ve seen where this can take much longer. When a backup is virtual booted, it is often discovering new virtual hardware for the first time. Network cards get setup as DHCP, performance is sub-par, and there are no backups happening while you’re using your backups. You may be up-and-running, but you’ve got a mess to work out with final restoration back to normal equipment.
Hyper-V Replication can allow a business to setup identical (or not) secondary physical hardware, cloning the primary host server’s virtual configuration. Since the virtualization parameters are identical, VMs happily boots on the replica server as if nothing happened but a dirty shutdown (in the case of out-right failure). In the best-case scenario, you can failover cleanly and perform test failover(s) to ensure your system works.
After setting this solution up at a client site, I was concerned to find that there was no adequate monitoring solution to ensure replicas are functional. Sure enough, for various reasons, replications from time to time failed. One time it was due to a new Anti-Virus deployment where the software turned off the TCP/IP ports that the replica services used to communicate. In another case, disk-space exhaustion caused replica services to fail. After looking around, I found some PowerShell “do-it-yourself” scripts on the internet. Finding none of those appealing, I decided to take the plunge and create my own solution. After creating a solution that worked for me based on PowerShell – I decided to create a professional, commercial solution written in C#, as a Windows Service, complete with an installer and graphical user interface. The solution is in production today, monitoring my clients. It is configurable via the GUI, which allows you to select all the properties you can obtain via PowerShell to get information necessary to suit your needs. It can email you alerts in HTML, CSV or plain-text.
Buy it here! https://iqspiral.com