Recently, a customer who’s already got a vSAN implementation in place, but only for testing purposes, asked me about the potential hazards regarding virtualizing some of their databases onto vSAN. To be fair, the initial conversation began with simply using VMware as a basis for some of their mission critical databases. Now, I’ve always been a V1 (Virtualize First) proponent, and can remember going back to my early days at EMC, wherein I did a well received presentation on virtualizing mission critical apps onto VMware. However, I’ve also been a realist in knowing that not every application should be a viable candidate for virtualization.
There are many reasons in which some apps may simply not be appropriate candidates to be VM’s. However, these have historically been due to functional anomalies, like hardware insurmountables like dongles, Unix operating systems like IAX or Solaris, or things like licensing characteristics wherein, for example, Oracle might demand licensing every socket in an entire environment in order to locate an oracle infrastructure into even only one segregated cluster. In the latter case, monetarily, this proved to be prohibitive. Incidentally, it seems as if Oracle is loosening their stance on this policy, and offering the option for the customer to prove the isolation of that cluster so that only the possible sockets on the hosts to which the Oracle app might be moved to be those that get licensed, thus alleviating a large amount of the cost which made it not cost-effective to do so.
I’ve long felt that even a single VM that consumes an entire ESX host would be preferable to standing that same machine up on bare metal. Things like uptime, vMotion, VMware snapshotting, etc. add so much functionality on an architectural level that to me, as an administrator to the VMware infrastructure, that it still was logical to virtualize.
We have so much power available now to allocate to individual VM’s, that virtualizing a database, even a high-transactional database, is not only acceptable, but preferable.
Adding vSAN into the equation, particularly today, with all its newer specifications, seems to me to be again, simply the logical choice. Now that all the IO issues are addressable, due to the option of an all SSD vSAN implementations, even mission critical databases have the ability to be delivered all the disc based IO that they require, along with the extended functionality of disc redundancy across hosts. vSAN not only improves the benefits that vSphere brings to the equation, but also increases that availability to an extent that hadn’t really ever been available previously.
VMware has some really solid reference architecture on virtualizing Oracle: Here
And Microsoft SQL Server (Albeit on the preceding version of vSAN, v.6.1):
These are really excellent references for the design, of the environment, and also some fantastic design points to follow when implementing the databases themselves.
I recently had the benefit of a presentation in Palo Alto from the vSAN team, including the always entertaining, and hugely knowledgeable Rawlinson Rivera ( @PunchingClouds ) who briefed us in the Storage Field Day crew (#SFD9) on the benefits of vSAN, and the newest features on version 6.2. I would be happy to expound on these, but rather, would refer you to the following:
Here are all the presentations we received: Here
So, with that in mind, I have to say that to the question: Should I virtualize this database? The answer is Most Definitely.
Virtuallytiedtomydesktop's Blog 
Matt, from a conceptual point of view, there’s no reason not to virtualise any particular application. However, there are a few considerations, that would be the case in any infrastructure. I’ll set aside discussions on performance, as I’d expect those to be done as a matter of course and I think your post refers more about reliability. From a reliability perspective, I think you have to look at VSAN and how things work in a failure situation, Node failure could result in significant data rebuilds, which would affect production performance, Now the latest version of VSAN (6.2) seems to be a lot better in this area. Also there’s the issue of checksums and data corruption; again 6.2 is a lot better in this area. Until VSAN 6.2 I’d have reservations about using it for production, but 90% of the issues appear to have been resolved.
I couldn’t agree more, Chris. This really was based on the v6.2 code set. The ability to cross clusters for disc redundancy really adds to the capabilities of vSAN. As always, “Let the buyer beware” and your mileage may vary. But much of the rebuild and replication seems far more acceptable today.