We're currently undergoing a major redesign of our hardware across the business (mainly due to a reduction in rack space!) and the pwers that be (who have little to no Progress experience) want to virtualise our main DB Server. Is this an acceptable thing to do, or are there pitfalls to watch out for?
The main risk is that they will attempt a cookie cutter "out of the box" configuration. A DB server is not a simple appliance that can be treated like some silly little thing.
Watch out for: "thin provisioning", "over subscribed", "shared" and "dynamic". Those are code words for "you don't really need any resources so we aren't going to give you any".
Database servers need to be provisioned for peak loads. Your peak is not the average usage over 24 hours. Nor is it what someone sees looking at 5 minutes of "busy" time in the afternoon. Peaks occur when you have to do unusual things -- month end processing, nightly data warehouse extracts, restore and roll-forward, index rebuild... and a lot of those things are done under pressure with all eyes on the system. You do not want those moments to be the ones when you discover that the system runs like molasses because the virtualization people didn't give you enough horsepower. (If it happens they will never admit it -- it will always be some variation on "Progress can't handle..." which is pure crap...)
If they have never heard of Progress tell them to pretend that it is Oracle. The needs are similar enough that if they actually know what they are doing you should get a reasonable result.
Thanks Tom! Didn't recognise your moniker on here.
So apart from making sure there are no actual resource issues then it's ok to have the DBs on a virtual server?
If done well there shouldn't be much impact. But if unguided and done by someone who is making unfounded assumptions about the needs of a database server and whose primary motivation is being cheap then it will usually be a disaster. Of course that's true of lots of technology decisions...
Thanks for that Tom! :)
I second Tom's sentiments. I've seen radical swings in database performance on virtual hosts; even on the same host. Typically it is tied to the experience and knowledge of the sysadmin. I've seen a proserve take over 15 minutes to complete. Something to do with the vmware "balloon driver". Apparently it didn't like a process allocating about 8 GB of RAM (there was 16 on the box). We disabled that nonsense and the DB then came up immediately like it's supposed to.
There have been a few recent conference presentations on virtualization that may be worth looking at.
John Harlow (BravePoint), PUG Challenge Americas 2011:
Guidelines for OpenEdge in a Virtual Environment
Mike Furgal (BravePoint), PUG Challenge Americas (& EMEA) 2012:
Virtualization Both Inside and Outside the Cloud
Libor Laubacher (Progress), Progress Exchange 2013:
Getting The Most Out Of Virtualization In Your Progress OpenEdge Environment
------
Update: fixed link
The last one is pointing to the same presentation as the first one!
Thanks Mike; fixed.
Thanks Rob - useful info in all three of them.
One more:
Lynn Reas (Skyward), PUG Challenge Americas 2013
As Tom and Rob pointed out - running DB server on VM is perfectly normal, especially these days anyway. If configured properly (provision, network and underlying storage serving vmdk/vhdx, resource sharing and allocation) you should not see any (major) negative performance impact. You probably don't want (too many) other VM sharing any resources with your production environment, but that's nothing special, the same applies when deploying on a real hardware.
Also there are other strengths of virtualization - high avail, replication, tested failover, ability to create a copy of production in a few clicks for testing/QA, central management, etc .... (as mentioned in PPTs pointed out by Rob).
Can't stress and agree enough again with Tom & Rob - make sure you do it right.
PS. With regards the VMware balloon driver issue: kb.vmware.com/.../search.do