SQL Server on a Virtual Server

  • Agreed. Virtual machines bearing SQL Servers need to be tuned according to the parameters provided by the virtualization software. This isn't all that different from what should be done with different "regions" on a mainframe (sorry if my terminology is incorrect here, I'm not a mainframer but I realize a lot of the "new" technologies in client/server are "reborn" technologies from mainframes).

    We have SQL Servers on virtual machines that service training classes of 30-100 people performing operations simultaneously ("Okay, everyone click the submit button!" followed by everyone clicking the button at the same time). We've not had much issues and have had, at this point, to only do light tuning. This is on VMWare ESX server. So you can run such effectively, at least from our example. Just make sure capacity is taken into account (if you needed a physical server without VM, don't think you can put a SQL Server in a virtual machine on the same class server sharing resources with other VMs and expect it to perform well) and tune as needed.

    K. Brian Kelley
    @kbriankelley

  • In reference to the obvious - is the Virtual Server software installed correctly??

  • VMWare can be great for training/development/testing environments, but I wouldn't want to run a busy production SQL Server instance on VMWare. 

    Virtual machines are all about maximizing hardware resources, based on the idea that any given virtual os will have times when it is not busy, and others virtual os's can take advantage of that capacity. 

    There are two problems with SQL Server on VMWare, first is that you are maximizing the less expensive part of the system (hardware) at the expense of the most expensive part of the system (software).  Second, SQL Server is already a virtual resource if it's used properly.  Meaning that many applications can be served by a single instance.  There are also pretty negative licensing considerations when it comes to SQL Server on a VM.  Each instance of SQL Server needs to be fully licensed.  It's possible to wind up paying for 8 SQL Server per CPU licenses on a server with only 2 physical CPU's if you have 4 virtual os's with SQL Server installed and each can see 2 virtual CPUs.  That doesn't strike me as a bargain.

    Also some of the performance benefits of SQL Server's memory pooling, threading, and I/O access are largely negated by virtual machines.  So in addition to the 20% - 25% overhead imposed by VMWare, you also don't get the benefit of SQL Server's threading and scheduling, etc...

    /*****************

    If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek

    *****************/

  • Actually, the most expensive part is always maintenance. And this is where VMs can reduce cost. Case in point: you want to apply SP4 to your SQL Server. You've run it through the dev environment and you didn't see an issue. But you put it in production and immediately started having queries fail. How do you recover from this? There's but one solution: uninstall SQL Server, reinstall, etc. With VMs, I don't have that pain. Before the SP4 install I bring down the VM, copy it somewhere else, start it back up, and then run the upgrade. If I run into a problem, no sweat. I delete the files, copy back in my old ones, and I'm back up and running without issue.

    I agree with you on the licensing part, but you could make a very large VM. And memory usage, etc., everything is very dependent on whether you are using GSX or ESX, at least as far as VMware is concerned. Yes, the OS doesn't fully manage memory, etc., like it would on physical hardware, but as VM technology improves, it'll become closer and closer to the "real thing." After all, VM technology isn't new. It's been around on mainframes for years. And it has proven itself there time and time again - in production.

    K. Brian Kelley
    @kbriankelley

  • Yes, hardware virtualization has proven itself for many years in the mainframe environment and more recently in the *nix world, but the hardware was specifically built for it.  CPU manufacturers in the x86 world are supposed to be building in support for virtualization, but it isn't there yet.

    /*****************

    If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek

    *****************/

Viewing 5 posts - 16 through 19 (of 19 total)

You must be logged in to reply to this topic. Login to reply