SharePoint virtualization is an oft discussed area of IT consolidation and thus features a number of opinions and guidelines. One of its most misunderstood areas is database virtualisation.
Whilst it is generally felt that the database foundation of the system should not be virtualized (as with almost all virtualization projects, the inclusion of the database layer is generally not considered best practice) this does not mean it should not be considered as it can provide a number of benefits in specific scenarios.
Database virtualization is always contentious, but it is important to understand why this is the case and consider the effect of changing technologies in this area before discarding it out of hand.
The main factors which cause concern here are the very intensive nature of IO performed by databases which puts great pressure on any disk array used to host such a virtual machine, and their traditional lack of compatibility with many virtualization platform’s tools, specifically around synchronisation of data and backup. As VMWare / Hyper-V, SQL Server, Windows Server and server hardware continue to evolve, particularly with a focus on virtualization/ cloud infrastructures, many of these concerns are, or already have been, addressed.
The fact of the matter is that you loose nothing in terms of tool compatibility in SQL if you virtualize it, you just also do not gain as much benefit from the virtualization in this regard as you would for other server roles / applications because the virtualization platform’s functionalities may not be compatible with SQL Server. So at worst this is only ever a “no net gain” operation. Secondly, as concerns IO load on the hardware, well this one is pretty simple really, can your setup handle the rigorous IO load required to deliver a swift and timely SQL service to SharePoint? This question is the same regardless of your choice of virtualized or non-virtualized deployment of SQL server. That is to say the main factor here is good capacity planning & testing in your virtual environment, not the ignoring of database virtualization as an option!
I’m sure we all remember the worries surrounding databases over SANs / with iSCSI. Both of which are standard solutions these days.
So don’t panic or “assume yourself” out of seriously reviewing full virtualization of SharePoint 2010 & it’s database(s), it is not only possible, but may indeed provide a boost to not only any current project, but also your ability to evolve your solution / approach going forward.
Additionally, one important option to consider, specially in test or SME setups, is the implementation of a non-virtualized SQL Server whilst virtualizing the rest of the SharePoint 2010 stack, this is even effective in a single server situation. The virtual host can also run a non-virtual instance of SQL Server. Having said that, virtualizing SQL Server can also work well as long as you ensure you dedicate an array of disk / spindles to it & it’s logs directly. In this situation you can achieve a strong level of fault tolerance with a pair of virtual host servers both running separate but synchronised copies of SQL Server natively with the SharePoint roles virtualized “on-top” of this via Hyper-V etc.
Suffice to say that you should not discount SharePoint Database virtualization, but also that there are a wider range of options available than you might first think when reviewing SharePoint 2010 virtualization.
A few additional resources may prove beneficial in your own research into the matter;
– Nice, quick summary of key points around SharePoint 2010 virtualization.
– Excellent example / diagram of the use of Hyper-V to achieve SharePoint 2010 virtualization.
– Detailed review of capacity planning SharePoint 2010 virtualizations.
– In-depth look at database virtualization.
– Independent view of some of the benefits of including Hyper-V R2& System Center in your plans.
– Older, but still very informative, piece on SharePoint 2007 virtualization.
– Clear online presentation on the topic.