Be sure to watch for our product showdown on virtualization software ii mid-2008. We'll show you how the products stack up against each other.
Diana May
SQL Mag

Diana12/21/2007 10:04:48 AM

Wavel,

Let's say you're really small company that only has a budget for a single server, but you need to run a SQL server 2005 x64, Exchange 2007 (requires x64), Terminal Server and a File Server. SQL and Exchange need x64, but you need the Terminal Server and File Server to run 32 bit for compatibility. One option is to purchase four servers (or maybe two but you would have to combine SQL and Exchange, File and Terminal Server. Possible, but not the ideal situation especially for the File and Terminal Server), but if you don't have the budget for that, you could get a larger server and run four virutal guests on it. You might have some money left over to put the host server on a 24x7 4 hour service contract.

To answer your patching questions, Blue Lane makes a in-line security product that works with VMware ESX. It will essentially "patch" all of the virtual guest running on a host running the Blue Lane product. Check out this link http://www.bladewatch.com/2007/03/15/blue-lanes-vmware-security-product/ for more info.

But, it sounds like you're already made up your mind, so probably running everything on dedicated hardware is your best bet.

Alan12/17/2007 11:30:28 PM

Alan:
Your statement that the biggest advantage is security is interesting. Assume that the Sharepoint server is compromised. What assures you that there is no possible way of getting to the files on one of the other virtual servers? Or even better: DOWNLOADING the virtual image for those servers!

You also said that you could create a fully patched instance in 15 minutes once you had your base image. But MS is patching monthly, so do you end up with new vm's that still need patching? Or are you updating the base file each month? And once your new vm is running, it needs to be patched seperately from all the other vm's right?

As for testing in a vm that's running on a production machine.... really?? Are you 100% sure that you can't crash the hardware inside the vm? Seems pretty risky to me.

The point I'm trying to make is that so far, I'm not seeing a good reason to run a vm. We are a very small company - every server we buy affects our bottom-line, so it's not an issue of us being a fortune 1000 that can buy as much hardware as we desire :) Every point you've made as a reason why you'd want to run virtualization, seems to have a valid counter-arguement against it. I'm looking for the one big reason that makes me slap my head and say "Duh!".

RICK12/13/2007 1:45:27 PM

Wavel:

Probably the biggest advantage in your situation is security. Assuming you need to run Outlook Web Access or Sharepoint, you can install a virtual server and only have that front end Web Server exposed to the outside. If you have everything installed on one machine and it gets hacked all of the data that resides on that server is vulnerable.

Since virtualization creates a consistent platform, it makes recovery much easier. If you have the virtual server images backed up, all you have to do is restore the image onto a new server and you're done. If you're not virtualizaed, you have to load the OS, install the backup software, install SQL Server and then restore the databases.

We've also found that running separate applications per server, reduces the possibility of conflict between applications. We've seen instances where corruptions in certain components can cause other items to fail on the server when they're all installed on the same server. For example, if the metabase in IIS is corrupted it can cause Exchange to crash.

If you're doing anytype of testing, it's very easy to create a virtual test environment, and take it down without messing up your production environment. Once you have your base images installed, you can create a new server in 15 minutes, that's fully patched and ready to go. That's pretty difficult to do with a physical server.

Even in small shops virtualization may have a place, espeically if you have to run 32 and 64 bit servers. I suggest playing around with the technology and start slow. If you're not sold on technology I think you will be after you've had a chance to experience it first hand.

Hope that helps!

Alan Sugano

Alan12/12/2007 1:23:09 PM

ge:

If you're experiencing heavy disk I/O, you could move to the x64 platform, load up the server with a lot of memory and cache everything. This will take a siginficant load off of the disk subsystem. Of course you have to use ESX which supports an x64 guest, and now supports up to 64GB of memory on a x64 guest. This is the same strategy that Microsoft is using for Exchange 2007. Run x64, load the server with a lot of memory and cache everything.

Thanks!

Alan Sugano

Alan12/12/2007 1:08:04 PM

I guess I need to be enlightened... the article ends with "...but the benefits are tremendous". What exactly are the benefits? I understand that if you needed to run different OS's, virtualization is a great way to save on hardware, but why do I want to run the SAME os multiple times? Since when did it become practice to have one app per os? If I need to run SQL, Exchange and IIS, why is it better to run 3 copies of the OS (each needing updating and configuration) versus running them all on a single instance of Windows Server?

If the answer is the ease of backing up the image files, the author even states that he's doing a regular backup of his sql data every 15 minutes anyway. And we have to assume that backup hardware is available in case the server crashes... why not log ship or mirror to the backup hardware?

If you really need seperate instances of sql server for all your apps, why not run new instances of sql? Doesn't that simplify maintenance, not to mention licensing?

Please point out the benefits to me.

RICK12/7/2007 9:36:47 AM

Hi, good to have some info on this, but I miss good information on the biggest bottleneck on SQL Server, Disk I/O, which is in Microsoft Virtual Server a big problem for performance. I have some experience in VMWare ESX, and the difference is smaller there, but be sure to test a real life load on a virtual server before stepping over to virtualization.

ge@familie-brander.nl 12/6/2007 1:28:46 AM

Thanks for this article Al. I have been using Virtual SQL servers in production for four years now and received a good deal of flake from DBAs for doing it. This article vindicates the decision that has seemed so obvious for a long time.

CURT12/2/2007 1:07:18 AM