1) the "disk" configuration you gave us is almost useless from an "is it configured well" perspective because you gave us no idea about the underlying IO subsystem configuration other than RAID type. A 1000MB "disk" could be a single 7200RPM SATA drive shared by lots of other stuff or it could be a slice of a 3-PAR 1000-spindle SAN that can support 300K IOPS. You, as the SQL Server DBA, simply MUST know EXACTLY what underlies each of your "disks" and also know anything else that might share the same IO pieces-parts.

2) VMWare can support MASSIVE amounts of RAM, CPU and IO now. IIRC 2TB RAM, 32vCPUs and a system was benchmarked at 1MILLION IOPS on the IO side. I assure you that a properly configured VMWare system can support your 300GB database with a few hundreds or a few thousands of concurrent users. I note that that doesn't actually mean your database and applications can support that!

If the VM host is ONLY going to host 1 VM EVER, then what is the value added by vmware? It's not free, and does introduce some (slight) overhead so it needs to be justified to be thrown into the mix. What is their justification?

Of course, if I was a shady sysadmin, I could say it would be dedicated to sql server, then later sneak some additional VM's onto it. That pesky DBA would never notice his server slowing down one day, and if he did complain, I could move the extra VM's off....

hardware abstraction. Zero issues in moving hardware from the windows side. Ease of migration to new hardware.

There are some nice benefits on 1:1 host:vm planning. Especially if you install this as a single node cluster (and you should think about it).

Steve/SpringTownDBA - The reasons listed above by Steve are the same that I was given for the use of VMWare and to my understanding it is a single node cluster.

One thing that this is NOT is cheaper. The additional license costs to use VMWare almost tripled the total cost of the server; at least thats what I was told. I admit I can not speakk about VMWare from a knowelagable perspective but it does NOt sound like a good deal to me when it drives up the total cost that much.

TheSQLGuru (7/27/2012)1) the "disk" configuration you gave us is almost useless from an "is it configured well" perspective because you gave us no idea about the underlying IO subsystem configuration other than RAID type. A 1000MB "disk" could be a single 7200RPM SATA drive shared by lots of other stuff or it could be a slice of a 3-PAR 1000-spindle SAN that can support 300K IOPS. You, as the SQL Server DBA, simply MUST know EXACTLY what underlies each of your "disks" and also know anything else that might share the same IO pieces-parts.

2) VMWare can support MASSIVE amounts of RAM, CPU and IO now. IIRC 2TB RAM, 32vCPUs and a system was benchmarked at 1MILLION IOPS on the IO side. I assure you that a properly configured VMWare system can support your 300GB database with a few hundreds or a few thousands of concurrent users. I note that that doesn't actually mean your database and applications can support that!

1) Well thats all I've been told so far and since I don't get to make the call (just provide input) I'm not so sure knowing more about the plan would result in any changes being made should it turn out that one or more of those decisiosns are bad. As far as knowing whats under the hood, pro-VM admins (at least in my experience) seem to take a "you don't need to know because VM is no different then non-VM" approach to the whole thing. I guess they figure if you know exactly whats behind the VW screen it might skew your perception of how its relaly performing. All I can do is make my reocmendations and show the metrics for our existing setup (Server + SANS storage) and maker recomendations on what changes shoudl be made from that for the new system.

2) I have read from pro-VM SQL gurus that running SQL Server on VMis fine so long as its done right and under the right scenario. My concern is, as you light heartidly joked about, that the app which uses the DB is not optimized to work with large DB's and so any additonal action taken that can impact performance will be magnified.

If the VM host is ONLY going to host 1 VM EVER, then what is the value added by vmware? It's not free, and does introduce some (slight) overhead so it needs to be justified to be thrown into the mix. What is their justification?

Of course, if I was a shady sysadmin, I could say it would be dedicated to sql server, then later sneak some additional VM's onto it. That pesky DBA would never notice his server slowing down one day, and if he did complain, I could move the extra VM's off....

hardware abstraction. Zero issues in moving hardware from the windows side. Ease of migration to new hardware.

There are some nice benefits on 1:1 host:vm planning. Especially if you install this as a single node cluster (and you should think about it).

Steve/SpringTownDBA - The reasons listed above by Steve are the same that I was given for the use of VMWare and to my understanding it is a single node cluster.

One thing that this is NOT is cheaper. The additional license costs to use VMWare almost tripled the total cost of the server; at least thats what I was told. I admit I can not speakk about VMWare from a knowelagable perspective but it does NOt sound like a good deal to me when it drives up the total cost that much.

Thanks

Just curious, do you have specs on the new server? mfg/model, number and type of processors, total ram, etc.

I wouldn't think that vmware would make up a huge percentage of the total cost of a large sql server but I'm not very familiar with vmware's pricing model.

From research I've done for our planned 2012 upgrade of our 2-node cluster, sql license costs are going to run 60-65% of the total.

SpringTownDBA (7/27/2012)[quote]Just curious, do you have specs on the new server? mfg/model, number and type of processors, total ram, etc.

I wouldn't think that vmware would make up a huge percentage of the total cost of a large sql server but I'm not very familiar with vmware's pricing model.

From research I've done for our planned 2012 upgrade of our 2-node cluster, sql license costs are going to run 60-65% of the total.

I'm curious too. Depending on the # processors & total RAM, it sounds like you could get away with an Essentials Plus license which clocks in just under 5 grand and is good for up to 3 bare metal hosts. Of course, if you add in all the other possible management bells and whistles the costs can add up pretty quickly. Then again you're using that across your entire infrastructure not just on this one host so the costs should be distributed.

ScottPletcher (7/27/2012)Tempdb drives are much too small. SQL uses tempdb a lot, and you can't afford to run out of tempdb space.

I would not dismiss RAID5 for the db data so quickly. Reads are faster on RAID5, although writes are much slower of course. Proper selection here requires more investigation.

I agree that tempdb data should not be on RAID5, since it is a higher % of write vs read.

I don't have the links anymore, but I did quite a bit of research a few years ago and that research pushed me away from RAID 5 to RAID 10 for my database servers.

Best thing I can suggest here is do your research, then make your decision. If I had to support this type of decision now, I'd be back doing my research as I know that just saying this is how it should be you need to know for sure.

Also helps if you can stress test several configurations prior to actual deployment.