What are the cons and prose using 1 POC VM spanning a whole blade vs multiple VMs on 1 blade?

From all you describe above due to the size and "traffic" - IO against your database(s) in my opinion it is inappropriate to use VM as if you use "one VM spanning whole blade " then what's the purpose for that? Better having a physical in my opinion as performance in VM is caped (as far as I'm aware up to vsphere  5.5 we're using) to max 8(12) CPU's and 16GB of RAM. As soon as we went up to 20CPU's and 24GB of RAM performance went actually down and we ended up having one whole VM consuming the host so...you will need to asses very well in my opinion if VM's are appropriate to run your SQL back end VS Physicals no matter what IT will tell you related to management.

"What are the cons and prose using 1 POC VM spanning a whole blade" - you just add one layer of unnecessary expensive software on top of physical host OS to manage not much.

Ideally the systems should be designed indeed to have "multiple VMs on 1 blade?" or 1 host but no matter what powerful host you have think that if you need more than 8(12)CPU's and 16GBRAM per VM image...better use physicals.

Thank you very much for explanation but do you think Flash Storage would be good for this setup?

Also, my biggest concern is storage access.  This is critical for high-performance database applications, and if our current physical servers have and utilize 2 HBAs then we will see a hit going to a VM which will at best give us one HBA worth of throughput to each VM.

What suggestions you will recommend for  high-performance database applications in case of moving toward VM?

Do you think this solution  will help me for 2 applications with thousand of transactions per minute?
There are two DB's each  is 1 TB

IT solution:

1 Blade = 2 CPU Sockets = 16 Physical cores = 32 Hyperthreads
Create 2 VMs – each with 16 Hyperthreads = 16 vCPUs dedicated to the same
Assign to each VM 500 GB Flash storage in the backend

Can you please explain?

I have a few questions before I can share my suggestions based on my experience and these are:

1. what do you mean by "Flash Storage"?  hope is not something like SSD you have in mind due to their limitation by design and I mean they will just "die" after the certain number of "writes" occurred right? so you'll need some good quality storage and fast network for that in my opinion.

2. you mentioned "There are two DB's each  is 1 TB" and my question is - are they on separate SQL instances and if yes my second question would be why?

3. you specified 16 cores per VM but not how much ram so if you have a physical with "2 CPU Sockets = 16 Physical cores = 32 Hyperthreads" and you want to "Create 2 VMs – each with 16 Hyperthreads = 16 vCPUs dedicated to the same" or 8 core each I believe you'r MAX RAM would be 24GB for each VM and from my experience as mentioned and unfortunately anything beyond that won't bring better performance no matter how big the host is - period! Well again, up to vsphere 5.5 we are currently running with various hardware but same results. So to add a bit more "stir" to this...compare the 16 vCPUs and 24GB RAM to what you have today and think what will you be doing when you are in production and things aren't going pretty well with performance, you added ALL indexes you can, code is optimized as much as possible, ETC...so you need to grow right? How will you be growing when VM's are not really designed to run lets say 40CPU's and 132GB of RAM right?

Besides all the above, you mentioned "There are two DB's each  is 1 TB" then "Assign to each VM 500 GB Flash storage in the backend" which is only half of one database right? Or in other words you'll need at least 3*500GB (SAN LUN's in my opinion) for each VM in order to support 1TB database on each VM running one SQL instance right?


as detailed here: http://androidpcreview.com/are-torrents-damaging-your-mini-pc/2237/
"...the flash storage, including Solid State Drives (SSD), has a finite amount of read-writes that it can perform before the drive just plain dies. No clicking like normal hard drives….just dead." so I would think twice putting my SQL databases on SSD's...but maybe I'm wrong.

Thank you

So, this is Prove off concept project to find best solution for out two separate databases

2. you mentioned "There are two DB's each  is 1 TB" and my question is - are they on separate SQL instances and if yes my second question would be why?

ANSWER: Two different data bases that needs to be move from our old servers to new VM environment or other solution.


3. you specified 16 cores per VM but not how much ram so if you have a physical with "2 CPU Sockets = 16 Physical cores = 32 Hyperthreads" and you want to "Create 2 VMs – each with 16 Hyperthreads = 16 vCPUs dedicated to the same" or 8 core each I believe you'r MAX RAM would be 24GB for each VM

ANSWER: IT Dept. did not specify how much RAM for each server. They said " a fully loaded 2 socket blade can have total 500 GB or more"


4. Besides all the above, you mentioned "There are two DB's each  is 1 TB" then "Assign to each VM 500 GB Flash storage in the backend" which is only half of one database right? Or in other words you'll need at least 3*500GB (SAN LUN's in my opinion) for each VM in order to support 1TB database on each VM running one SQL instance right?


VM1 = Pwerewre Replacement POC VM:        16 Physical Cores of CPUs – configured as 16 vCPUs,  256 GB RAM, 1.5TB regular disk plus 500GB flash  (deploy sql 2014)

VM2 = AXXXXX Migration POC VM:              16 Physical Cores of CPUs – configured as 16 vCPUs,  256 GB RAM  1.0TB regular disk plus 500GB flash       (deploy sql 2014)

Thank you so much