Databases, vSphere and vSAN

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):

Here

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.