Juggling server virtualisation and database workloads As the conversation moves from generic virtualisation of ‘quick win’ workloads such as web servers and print servers, development and test environments, one-off applications and so on, the question arises – where does server virtualisation go next? One potential area is to see virtual machines as a target for database …
If you don't care about performance then you can use VMs, but what would be the point?
Sybase, Oracle or DB2 can easily run multiple work loads and control who uses how many CPUs and so on. So, if we take Sybase as an example, I can run, let us say 100, databases on one Sybase server. I can restrict logins to certain CPUs and impose other limits, dynamically. So, I can achieve flexibility and fast deployment without the overhead of VMs.
Perhaps in development if you're going to throw the environment away, but otherwise you'd have to be mad to go down the VM route.
This certainly what a lot of my clients have found anyway......
It's not at all clear to me why database virtualization makes sense. No-one (with half a brain) virtualizes just for the hell of it; the goal is consolidation. Well, for decades (literally) we have been able to have multiple database instances and multiple versions of the database software coexisting on a single host, and been able to move these around a cluster. Virtualization (particularly in the case of Xen which is flaky as hell when it comes to traversing large memory structures) gives no advantage and just adds complexity and more failure modes.
"However, running multiple databases in multiple VMs on the same server can only be of limited use, for the simple reason that they will all be accessing the same disk."
This does not seem to make any sense. Maybe he meant running the same databases in multiple VMs on the same server?
We run all our DBs entirely in VMs. A simple MySQL instance for powering a small website has absolutely no problem being inside a VM. Ever our MSSQL instances backing our production apps don't blink at being virtualised. This means I can enjoy all the benefits virtualisation brings while quietly ignoring the fact of hypervisor overhead.
Now, if you were running databases of the class where you start measuring your disks in IOPS rather than GB of capacity, then yes, virtualising that database is probably a Very Bad Plan.
Let's face it, virtualisation is not 100% efficient. You will not be able to achieve the maximum IOPS from your disk array if you have the overhead of virtualisation. Not only that, but if you are measuring your disk arrays in IOPS, you are probably absolutely pinning the CPUs attached to your database servers. There's no benefit to be had from virtualisation in that scenario.
The benefits virtualisation can bring exist entirely in the "my database is small enough to not really impinge upon modern hardware" realm. Get tot he point that your DB starts actually using the hardware it's on, and virtualisation will hinder, not help.
(All of the above in mind...a virtualized mirror of your DB is sometimes a good idea. It might not be as fast as the primary, but it doesn't have to be on a dedicated system to serve as an emergency backup...)
The reason I consider having virtualised database servers is pretty simple in my (admittedly simple) mind.
If I have a fully populated blade centre (7-14 servers depending on who we're talking about), all in a single VM pool, and I then fill 33-50% capacity with Virtual machines dedicated to database server work, I can further fill out the other 50-66% VM pool with Application/web/file server VM's... Probably squeezing upward of 200% capacity out of the given rack space...
All this with the added benefit that if 1-3 (based on 7) of the blades died... everything would keep ticking along as the VM Manager automagically redistributed the VM's from the failing hardware...
If I'm way off mark... tell me... cause I'm constantly urging my DBA's, Server specialists and Infrastructure manager to try this out.
Nerd Icon - Cause in the end... if You ain't got that much brains... you may as well be management.
Fault tolerance / high availability.
Portability / ease of hardware upgrades.
blah blah blah..
If you are worried about performance, you should think about using SSDs anyway. Makes for I/O heaven :) I've got Windows VMs that boot from off to completely booted, all apps loaded, in under 5 seconds. I luuurve SSDs :)
vSphere hosts can scale up to 250000 IOPs.. That satisfies most database servers. Unless you're Google or someone :)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
