Hi,

First posting on this thread, sorry if I am going to sound like a noob (I am a noob when it comes to servers).

Our agency is looking to give us a MS Virtual Server 2008 for our new project, a data mining application (ISYS). I would like to have it run on the fastest environment as possible. Besides having a large dedicated RAM (16Gb) and a quad core CPU (Xeon X5460 - 3.16GHz) on a 64bit OS dedicated for this VM, I was also able to convince my IT to physically dedicate a storage hard drive to reside in the same box as the virtual server physically resides.

Is there any other options that I can have to increase the performance of this VM machine?

Since it will be used for Data Mining, I am assuming that there will be heavy I/O operation when the software is indexing the databases. It will be touching other database servers as well as a web-server for indexing purposes but will not be storing and data on the SAN.

Any suggestions will be appreciated.

Thanks

Safa
 

Are you saying that you will have 16GB RAM and 4 logical processors dedicated to this VM guest or are you saying your VM host server has 16GB of RAM and a single Quad Core CPU? Hope it's the first one I mentioned.
Having direct attached storage will defintely be fast, just make sure you stick with fast SAS drives and not SATA (not that SATA is bad, but heavy I/O loads are better on SAS drives) for this instance. Having a dedicated NIC for this VM will help as well so that it's not in contention with other VMs sharing a NIC.

That being said, before you do anything you need to make sure, even though it will be on a VM, you need to follow the same physical server specs recommendation from your ISYS company to create the virtual machine. So if the harware specs from them call for a 4 processor CPU, 16GB of RAM, 1Gb network, 300GB 15K SAS RAID whatever config, etc..., then that's what your VM guest needs to be able to do; so your VM host server better be spec'd much, much better to handle it along with the other VMs you might be running now on it.

Thanks for the response cajuntank.

Our Servers that will host VM has 4 logical Quad core Xeon's and each of the logical Xeon's are assigned to single VM (total of 4 VM is running on a single physical server). Also the regular VM set-up was for 4 to 8Gb of memory for each VM but I was able to convince the IT to give us 16Gb of dedicated RAM for this VM.

The advised hardware specs from the vendor is to have Win Server 2008 (32 or 64bit), (our VM is 64bit), 180Mb of hard drive space for the software install, 1Gb of dedicated memory for each index, up to 30% of the original  size of the database to be indexed for the index file creation storage.

They advised to have the indexes stored at the physical server that the VM is being hosted at a logical drive instead of on the SAN which makes a lot of sense. I am now trying to convince the IT to use the 300Gb SFF 15Krpm SAS RAID drives for the index storage instead of the 10K SAS RAID drives for the data storage. Do you think that there might be any other factors that can speed up the VM other than those?

Thanks for any help and advice.

None off the top of my head that I didn't previously mention except that when it's time to choose a VM disk type, your options will be pass-through, static or dynamic VHD. Pass-through will be the fastest disk access since it does not have to go through a "software driver" to access the media, static will be the next fastest, as while it does have to go through the driver, the space is already set so it does not have to "grow" the VHD file. There are articles you can Google that discuss the performance differences between all three and how with the 2008 R2, some are negligible. But again, your software provider should be able to offer you guidance on their recommendations for their software under a VM environment.

It's unclear here exactly what your situation is regarding the virtualization platform (Hyper-V?  VMware?).  You mention Virtual Server, which was replaced by Hyper-V 3.5 years ago, so I'm assuming that's not it.

Regarding the rest of it, you need to understand that a virtualized infrastructure does not behave the same way as a physical infrastructure.  Typically your virtualization administrator will know better than you how to maximize the performance of your VMs, and can assist with performance tuning to ensure that your performance requirements are being met.

The biggest glaring problem that I see so far is the discussion about using a locally installed disk mapped to the VM rather than storing data on the SAN.  Using that sort of configuration will preclude you from being able to leverage the high availability features available with a virtualized infrastructure.  On top of that, it may also provide worse performance.  Typically a SAN will consist of dozens (or even hundreds) of high performance disks, as opposed to one (or a handful) of disks available with direct-attached storage.  Having the data spread across more disks can dramatically improve performance from a throughput AND latency standpoint.  Obviously this can vary depending on your SAN configuration, but I think that you'd be hard-pressed to match the SAN performance using direct-attached storage.

The second glaring error is when it comes to resource allocation.  If your application requires 8GB of RAM, why would you insist on 16GB?  By allocating more resources than the application can use/would need you're actually wasting resources that could be allocated to other VMs (unless they're using a feature like Dynamic Memory).  Similarly, your assumption is that with 4 quad-core CPUs each of the 4 VMs is getting a full 4 CPU cores.  That's not the case, as the hypervisor also reserves some compute cycles for itself.  More to the point, unless your virtualization administrators are doing a lot of seemingly unnecessary babysitting of the VMs, there are no CPU affinity rules created.  Your program may execute on one physical CPU for one command/instruction and then onto another physical CPU for the next command/instruction, depending on what the overall workload is for the server.  With features like Core Parking you may find that with a low workload that half of your CPU cores are idled in a low-power state and all of your VMs are executing on the other half.

Generally speaking, I recommend that you simply provide the ACTUAL requirements to your virtualization staff and let them worry about the details of how disk/CPU/memory are allocated to meet those requirements.  I find that typically when application owners who don't understand the virtualization platform get involved in making those decisions they end up doing things that they THINK will help performance that ACTUALLY end up hurting them.  Then they complain that virtualized solutions can't meet their needs.

________________________________________
CompTIA A+, Network+, Server+, Security+
MCTS:Windows 7
MCSE:Security 2003
MCITP:Server Administrator
MCITP:Enterprise Administrator
MCITP:Virtualization Administrator 2008 R2
Certified Quest vWorkspace Administrator

Quote:

They advised to have the indexes stored at the physical server that the VM is being hosted at a logical drive instead of on the SAN which makes a lot of sense. I am now trying to convince the IT to use the 300Gb SFF 15Krpm SAS RAID drives for the index storage instead of the 10K SAS RAID drives for the data storage. Do you think that there might be any other factors that can speed up the VM other than those?

This actually doesn't make sense. By not storing your data on your san, if that host goes down for maintenance or dies then your system goes down. It is also highly unlikely that your local raid card in the host server can produce as much IOPS as your SAN can provided your san is properly setup.