Sharing of thoughts and information is what blogging is all about. This way we can learn from each other. Post A Comment!These postings are provided "AS IS" with no warranties, and confers no rights. You assume all risk for your use.
Anthony Bartolo Twitter | LinkedIn
Pierre Roman Twitter | LinkedIn
The following article is written by Mitch Garvis (@MGarvis) and also appears on The World According to Mitch.
Microsoft created Windows Small Business Server as a one-box solution for companies that did not need more. It has always been a hobbled product, based on Windows Server Standard, but limited in things like domain trusts, FSMO roles, and more.
Of course even if it were based on Windows Server Enterprise, the idea of creating a failover cluster for a product designed to be a single-server solution seems a little silly… or at least it would have in the late 1990s, when SBS was first delivered.
Welcome to the world of virtualization and the free Windows hypervisor.
Over the past several months I have written several articles on using free tools from Microsoft to create a failover cluster using the free Hyper-V Server 2008 R2 SP1 as the hypervisor, and the free Microsoft iSCSI Software Target 3.3 as the Storage Area Network (SAN) device (see the articles outlined in IT Pro Connection & the TechNet Flash for details).
While it is not licensed to be a virtualization host, there is no reason why Microsoft Windows Small Business Server cannot be a virtualization guest. Of course, it would require a little extra planning – if you plan to use the Fax service, for example, or if you rely on USB hard drives for your backup – but other than that, I am not aware of any limiting factors.
In this diagram you see the physical infrastructure required; the Virtual SBS box resides on the iSCSI Target and is homed by one of the nodes in the cluster at any given time. It should be noted that this can be expanded to up to 16 cluster nodes, but two is not uncommon for smaller organizations.
This solution, it should be mentioned, it not free. There are a number of costs involved, which I will outline. However for a small organization that knows the dangers of their entire business relying on a single piece of hardware, the costs involved are often less than the potential downtime should your physical server fail.
While there are other costs involved (storage, networking) they are all a big ‘it depends’. If you do have a SBS box that your business relies on, and you cannot afford downtime (who really can?) then these costs should be factored into the cost of doing business, and should be considered business critical. In other words, invest in proper server hardware (HP ProLiant is a good choice!) rather than trying to do it on the cheap with white boxes or even worse, workstation-class hardware. You may not think to thank me for it when everything is running smoothly, but you will remember reading this and regret not following my advice if you do not heed it and everything comes crashing down!
One more thing you should always remember: Take the time to familiarize yourself with all of the tools involved. Build it in a lab environment that you can try out and make mistakes on before finally implementing the real thing. When you do build it, TEST IT… Failover Cluster Manager has a feature to simulate cluster node failures… or if you want to really test it, try unplugging the network cable from the owner node. Your Highly Available SBS should restart within seconds on the second node.
Remember that you are now adding a level of complexity to your SBS environment that you never had before, and one for which SBS was not designed; it will work, but as you are now working outside of the box, you have to start monitoring outside the box. Make sure that your cluster is healthy every day; if you have a tool such as Microsoft System Center Essentials 2010 that monitors your network, implement the Clustering Management Pack. If you use a third-party managed service provider (such as CharTec) then make sure that they know to monitor this solution for you.
Now that you know how to do it… Plan, Implement, and Enjoy! I always welcome your comments on how you loved – or hated – my recommendations
While this can work it should be noted that, in effect, the process of an unplanned failover in this scenario is the same as unplugging your SBS server and plugging it back in. The virtual machine memory is running in the physical memory of the host it is running on. If that host fails the running state of the VM is lost requiring the VM to restart on the new host.
While the OS should be stable enough to survive a hard shutdown the services, most notably Exchange and SQL, can incurr severe damage (corrupt DB, transaction logs, dirty shutdown, etc..) which can lead to signifigant issues with those services and associated effort to repair them and bring them back online. Microsoft does not support Exchange or SQL in this type of high-availability scenario.
Live Migration will work but does not protect against unplanned failovers.
Rodney, you are correct that a hardware failure will cause a restart on the surviving Hyper-V host but will get the SBS virtual machine up and running more quickly than trying to repair hardware. While care always needs to be taken when starting critical services like Exchange and SQL Server, with SBS2008 and SBS2011 SQL Server should be run on a different machine if best practices are followed. Exchange has also gotten better at dealing with failure but it is always a good idea to check the status after a failure.