August 30, 2010 at 2:57 pm
I would like to know opinions from other people on which would they prefer. We are setting up a non-prod environment. N/W team has suggested to go for VM, i think if we have multiple instances on one physical box we can get the same trhought put plus will save the cost of VM license and also usage by OS. CPU can be restricted instance level with MAX DOP, Memory can be set instance level, what else do we need which VM can do? Am i missing something here? Thanks
August 30, 2010 at 3:34 pm
I like VMs better. Easier to slide to another machine, and I think the memory split can be more efficiently used.
With instances, you can't really control one v the others very well.
For dev, it might not matter. Ultimately if someone overwhelms the box, you can move their instance, or go complain to them.
Not sure how licensing works. Most people I know don't pay by the VM, and the dev licensing for SQL should be the same.
August 30, 2010 at 5:03 pm
This is another of those "every dba has his own thoughts" issues.
You didn't say why the N/W team want to go with VMs, and this is critical. If they don't have a good reason, then don't do it.
In general I'm against VMs, although in dev it's not so much of an issue. One of the big issues being that Microsoft will often tell you to "replicate the error on a physical server" before they will help you solve issues on VMs.
I've also seen a tendency for sysadmins to build VMs on hyperthreaded hosts, then assign 1 "CPU" to SQL and wonder why performance sucks.
The only real benefits of VMs is the ability to trash and rebuild then if you want to, or to v-motion them onto other servers. Upgrades are maybe a bit easier. The thing to ask is "How often do we do this in dev?"
As Steve says, licensing isn't an issue for SQL if you are using Developer Edition (I don't know the VM Ware or OS Licensing implications).
You can use other features, like CPU affinity (rather than MAXDOP) to associate certain CPUs to a given instance. You can restict the amount of memory to ensure each instance has enough RAM (or let SQL manage it).
In a dev environment, what risk is there to the business if you need to rebuild a server and what are your SLAs? All the normal rules apply, backup the DBs, the registry and take system state backups. You one big risk is if you lose a major component of the server, but that can also impact the VM.
You also need to consider how you want to replicate your prod environment. My one issue with using named instances in DEV is if you only use default instances in prod. you then have to be aware of the changes to the connection string when you take an app live.
Cheers
Leo
Leo
Nothing in life is ever so complicated that with a little work it can't be made more complicated.
August 30, 2010 at 5:40 pm
Steve Jones - Editor (8/30/2010)
I like VMs better. Easier to slide to another machine, and I think the memory split can be more efficiently used.With instances, you can't really control one v the others very well.
For dev, it might not matter. Ultimately if someone overwhelms the box, you can move their instance, or go complain to them.
Not sure how licensing works. Most people I know don't pay by the VM, and the dev licensing for SQL should be the same.
I do like the point brought up about easily moving an instance in a VM.
I wonder if the Resource Governor would be of any help with the Multi Instance issue though?
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
August 31, 2010 at 8:16 am
thanks everyone. This was for a dev environment, but i was just trying get thoughts from other DBA's about VM.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply