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


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.

  • Yeah, you've hit on an issue. Microsoft OS's and Applications will demand all the RAM you give them. The issue is always that they don't like to purge memory in use once they grab it. I've seen examples, btw, of SQL apps that work more efficiently when granting less memory. Still, until these platforms are more elegantly written, you'll see these kinds of behaviors.

  • I'm having some issues with some primary pollers writing to vcloud virtualized SQL Servers... ours has never had a much memory as they show in that pdf... 128G they say... although I guess SQL server will eat any memory you give it.

  • Thanks for the positive feedback. I couldn't agree more. Orion helps, certainly, and I do aim for universality in my postings... Education is what I do and I thank you for agreeing with my perspective.

  • Comparing this Geek Speak topic and thread to others, I'm disappointed (but not surprised) to see it generated only half the views of other subjects, and many fewer bookmarks and comments.

    Perhaps it's only due to the more specialized topic, or to there being more NPM fans than database/v-sphere/VSAN folks present in Thwack.

    But it's everyone's loss for passing this story by.  Is there an IT shop that doesn't leverage VM (or want to)?  Is there any IT shop that doesn't use databases?  I'll grant that not everyone may use VSAN, but folks ought to at least KNOW about it as an option, and be ready to present its pro's and con's.

    If folks aren't leveraging Orion modules to maximize their products' performance, they're not doing all they should to improve their products and services.

  • Thanks for the feedback. I've also had these experiences and am glad that you have had them as well... It's always nice to be validated, right? Today, I think that FusionIO is a pricey solution that can be addressed in different ways, but I'm fairly confident that at the time, you'd solved it and beyond.