Database server on VM

[time]

Has anyone experienced or seen a database server running on a Virtual Machine, i.e. VMWare or Virtual Server?

Google tends to confirm my instincts - that disk I/O will be crap and therefore server performance will be crap. What do you guys think?

 

[P5-133XL]

Yes, you are correct that a VM adds an additional layer between the HW and the application so it will not run as efficiently as a native machine. However, that inefficiency may not matter as much as the ability to better use the other resources of that machine. It all depends on your needs and your budget.

One thing that really matters here is to have dedicated hard drives for the specific database VM (Put all the virtual HD's on their own dedicated drive). What you don't want is to have different applcations competing for databases the HD resource -- That can drasticly speed up your database.

 

[time]

We're concerned about the affect on performance. The DBMS is Oracle and there will be more than one instance (at least one each for 9i & 10g). There are multiple schemas in each database instance, collectively totalling 100 to 200GB of disk space per instance.

So there'll definitely be contention for storage access within the VM. But I suspect we will also have to share a SAN or local RAID with other VMs ...

I just can't see how inserting a VM layer won't be significantly worse than running these instances natively on Windows 2003 (or Linux, but I imagine this will be Windows).

 

[CougTek]

I know VMware performs worse than VirtualPc/Virtual Server for disk I/O. Otherwise, they are similar. For a database, if you go the VM way, you should opt for the Microsoft solution. I rarely push Microsoft's products over any other, but in this case I do. I prefer VMware's ease of use/configure, but not its performance hit on disk I/O.

 

[P5-133XL]

Again, the performance will be worse but the question is how much. My suggestion is actually test it and see if you can live with the performance decrease. The less contention the better and there is nothing stopping you from having multiple virtual hard drives on multiple independant HD's but the same is true on a native machine. So you try to optimize configurations and test your specific database against each other.

P.S. the other potential issue is the network interfaces. They also have an additional layer so if you are network bound then that may be an issue. The same can be said about the CPU. But everything can be tested ...

 

[Mercutio]

I've done Linux/MySQL and Server2003/SQL2005 on VMware and found that it's acceptable for small datasets and classroom use.

 

[time]

Unfortunately, there's a specific corporate division that provides these facilities, and it doesn't look like we're going to be given a chance to test the config. So we're worried that the results (there will be two or three such servers) will affect productivity and worse, may be difficult to fix.

Mark, I very much doubt that there will be physical disk systems dedicated to our needs - that's probably the crux of my concern. Whether a SAN (if there is one) offers enough of a performance advantage to offset this is one of my questions.

Cougtek, thanks for the insight. I'm still not sure whether people are referring to the 'VM' as VMWare by mistake. If not, we are really screwed.

 

[P5-133XL]

If the database is an important production system and you can't test the choices, I wouldn't move it and take the risk. The potential for the performance to tank does exist. Further, you will have a lot more risk in the future because once on a VM it is now dependant on a lot more variables as other applications and VM's start using resources on the same physical machine.

What do you think will happen, if someone else puts 2-3 more VM's on the same physical machine and each one has a different database? Even if the performance was good before, it won't be after that. You really need to be able manage the resources when putting something on a VM. That's the whole point of using a VM - To more efficiently use all the resources of a machine. If you lose control then sometime, someone will decide there are spare resources to use and basicly screw you without thinking. So basicly, I wouldn't put it in someone elses hands, unless you have no choice.

 

[time]

See, there's the thing, it's not a Production database, it's a Development and Testing database(s) for a fairly complex (and expensive) product. There are upwards of 20 people using it every day, at least some of whom (eg. the testers) are trying to put it under stress, while also running multiple sessions. Benchmarking is problematic - on the old server, a full table scan on one table is blowing out to half an hour when the server is under load. Whereas on a dedicated server with 40GB of RAM, we're talking 20 seconds.

The project is bedevilled with political issues - I'm just trying to confirm whether I'm justified in kicking and screaming about this proposal before it's too late.

 

[Howell]

I setup a client running 7 or servers under XenServer and the XenSenver itself and all VMs boot from SAN. They are using a smallish Sage accounting package and Citrix.

So they're willing to test it "on a dedicated server with 40G of RAM" and I presume dedicated disks but they are unwilling to test it under their preferred configuration? There is no amount of reading that can sufficiently predict how a particular implementation will hold up. You must test.

It sounds like they are willing to test on the fly.

I would ask if resources are available to do proper testing if this does not work.

 

[Howell]

They are running multiple SQL databases.

 

[Handruin]

We currently run a couple SQL Server 2005 databases in an VMWare ESX cluster at work. We chose this path for a bit more flexibility and reliability with use of vmotion and DRS. I only mention this if it's something you'll gain access to in your new VM environment. I agree that the extra layer does add some penalties/overhead for disk I/O and within the past few months we've made the move to push our main production database off of a server 2003 VM and into a bare metal server 2003 MSCS (cluster). We still use VM's for database development and testing, and will be moving all production to the cluster. In my limited testing, I did find that the I/O was a bunch slower in the VM than compared to the bare metal hosts. However, to be fair, we have 15+ VM's sharing three SAN drives, one of which is for the SQL Server. If we planned differently, I'm sure the I/O could be improved.

I know you don't have control, but I do agree that if you get stuck with a busy Oracle server on a VM environment, your best bet it to leverage some type of multi-pathing to a SAN (if possible) and try to get each DB onto it's own LUN/spindle. If you happen to be lucky enough to get into a VMware farm with ESX and vmotion, the DRS feature is very nice for automatically shifting around VM's based on loads so that you don't get stuck with one ESX server bearing the brunt of multiple VM's with high I/O.

 

[Howell]

For comparison, my implementation is using the outer edges of 15 spindles with dual fiber connections to the host box. Otherwise the SAN is also hosting lots of other data. We are up to 6TB I think.

 

[Will Rickards]

I run a monolithic VM in VMWare all the time with SQL server 2K, IIS and our services on it. Our software is designed for law firms and can be very expensive depending on the number of users and requested services.
I probably wouldn't let customers use it but it is fine for like 3-5 people doing development/testing.
We have similar VMs that the developers here share. Again it works fine for us.

We usually don't recommend running the DB server on the VM. We have clients that run the application servers as VMs.