Showing results for 
Search instead for 
Did you mean: 
Create Post

Databases, vSphere and vSAN

Level 13

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.


Interesting....  I have seen oracle on clustered virtual aix servers so the concept isn't new regarding virtualized databases.

SAN based storage for such was challenging.  The new SSD based storage option I will agree has improved that quite a bit.

I will go and refer to the links you posted to see the presentations.

Thanks for posting !

I appreciate the flexibility and speed of server building and restoration that VM has provided, and I've grown accustomed to it working well.

But early impressions were poor compared to the old-style stand-alone dedicated server hardware for a given app. Perhaps it was that our VM admins didn't fully understand the technology, perhaps we were skimping on the amount of resources an app could have on a VM host, or maybe things are just better optimized today with new skills sets from better training, or from better/bigger hardware.

In any case, we ran NPM for years on dedicated stand alone servers and were used to a specific response from the app.  When we first moved NPM to VM we lost that fast response, and things became much more ploddingly slow.

Now, five or more years later, I'm satisfied with how our pollers run on VM. But my team had to buy our own dedicated blade in the UCS chassis before we had enough resources to get NPM to work satisfactorily.

It's definitely much more comforting now to be able to take a snapshot of the server before making any upgrades or changes, and be confident in knowing that VM makes restoring MUCH easier than the old stand alone servers did.

Level 13

I think that before you determine where the fault lay in your attempts to virtualize NPM prior, you need to size up where that gap in performance exists. Is it in Disc access? If so, vSAN would potentially resolve that. There're many possible causes for that sluggishness. My point was, while your mileage may vary, doing so today makes so much more sense than even before when there were more performance tweak limitations than there are today.

Level 11

Although I haven't had to deal with a system that would require the majority of blade resources I am sure they exist.  Virtualization has come a long way since my first exposure running VMware on dell hardware.  Good article, thanks for the presentations.

Level 14

Good read.  Thank you.

Level 21

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.

I completely agree with you on this and we actually have our Orion database running this way without any issues.  The flexibility that the virtualization gives you just can't be beat.

We have actually successfully virtualized some very high I/O databases without any issues.  It certainly requires some very specific configurations and tuning but it can be done.  In one case we even used a FusionIO card for storage and it dropped some of the reports that were being ran from the database from hours to minutes.

Level 13

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.

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.

Level 13

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.

Level 20

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.

Level 13

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.

About the Author
Hi, I'm Matt Leib. I'm an old dude, with years on the customer side, years on the vendor side, and now, years on the channel side. Exist as a Pre-Sales Solutions Architect in the channel space. I specialize in virtualization, orchestration, storage and cloud. On my personal blog, I talk about anything from baseball and music to most technical things I enjoy including personal and enterprise tech. For the last few years, I've been a Tech Field Day delegate, and a blogger on Thwack's Geek Speak as well as a personal blog site at . Always learning, growing (though sometimes, that's the waistline) and striving to be as good as I can. I also like to sing, play guitar, and am a rabid Cubs and Blackhawks fan. I live in Evanston, IL, a suburb of Chicago, also grew up here. I work for Connection Enterprise Solutions, in a strategic solutions role, speaking to C Level on Corporate IT Initiatives