I’ve dived full on into the HyperV world with the release of Windows Server 2012. In Windows Server 2008 R2, it was a good platform for small businesses, as it provided a nice environment for running a business system (SBS2011 or earlier) with another server or two for other applications and uses. WS2012 makes it so much more powerful and easier to work with. I know I have said it before, and I will say it again. HyperV Replica is one of the best features for small business in WS2012. It provides an instant out-of-the-box disaster recovery capability at zero cost, since it is included in the software.
When I looked at traditional DR scenarios for small business, I believe that there are 3 possibilities to implement this solution. I know there are many other alternatives, but I feel that these 3 possibilities would be suitable for many small businesses, especially those under 25 users. Most small businesses do not have the budget to implement a 24×7 runtime environment and are satisfied to have some sort of changeover time in case of a server failure. Therefore, minimising this downtime window is important and greatly beneficial to the small business.
In discussing these scenarios, I am assuming that there will be an Active Directory, hosted on a virtual SBS or similar domain controller. The business would primarily have a single host server, but with the reduction in hardware costs, some businesses may have a second server, even if it is a lower spec server.
Two HyperV Host Servers in Workgroup.
In this scenario, there are two host servers. Once of the hosts might be in a different building or in a branch office connected via a site to site VPN link. The primary server would host the VMs and replicate to the second server. The second server might have a VM or two and replicate these back to the main server. This scenario works well because the host servers are completely independent of the underlying domain. However, there are some challenges in implementing Replica with workgroup based servers. Also, another important feature in DR, Live Migration, is not available for non-domain joined host servers.
Two HyperV Host Servers joined as member servers to the business domain.
In this scenario, the two host servers are joined as member servers to the underlying business domain. This makes management of the servers easier, since they are part of the business domain. It also enables the use of Kerberos authentication, and allows Live Migration to be activated. However, this obviously creates an issue where the member servers will be up and running before the DC is started. With cached credentials on the host servers, this issue can be negated. Alternatively, a second DC running on the other host server, as in a branch cache scenario, will also work to provide domain authentication. A variant to this alternative would be to make the primary host server a domain controller as well, so that it could provide the necessary authentication. However, the trade-off in this case will be some performance.
Using a HyperV Server 2012 (free) as the replication target.
In this scenario, the business may not be able to afford two full HyperV host servers. A second smallish server (like the HP Microserver) running the free HyperV Server edition could be used as a DR solution. I have found it very difficult to set the DNS suffix on the free HyperV server, as I have been able to do on the full GUI HyperV server. Powershell is not my forte, so perhaps someone with the experience can post a solution to this? (edit: thanks to some of my MVP friends, I might have a solution, and will test it out) If the server name is not properly configured as a FQDN name, it will not be possible to set up a certificate, which will render the workgroup method for replication useless. Thus, this scenario works best where both the host servers are joined to the underlying business domain.
A note about backups. In the scenarios above, a separate backup solution is still deployed. HyperV Replica is not a replacement for backups. There still needs to be a data backup plan in action to ensure that business sensitive and critical data is properly backed up and previous versions are accessible.
A lot more thought needs to go into this, and certainly, one should consider all the options before locking in a solution. I’m open to suggestions.