February 22, 2012 at 9:15 pm
Comments posted to this topic are about the item Future Virtual Machines
February 23, 2012 at 1:25 am
Of course, with your new setup, if you have a major physical drive failure you still need to reinstall whatever host OS you're using and put VirtualBox back on it... 🙂
I've never been too convinced of the benefits of virtualisation for something as memory and disk intensive as SQL server, though. I suppose these days, with the actual databases often residing on SANs, that gets rid of the disk argument, but what about RAM?
February 23, 2012 at 3:15 am
I use virtual machines too. VMWare Fusion on my Mac is great.
Using snapshots is how I'll test new software. If I want to revert back to the way it was before the install, I activate a previous snapshot.
Using Virtualization allows me to test software with different versions of IE. How many versions of IE can you install on one OS instance? One! So, you can have several virtual machines with each version of IE to test with. Also, you can test with XP, Vista, Windows 7, Mac, etc. I don't know what I would do if visualization was not a possibility.
February 23, 2012 at 5:15 am
I'm a Mac user, and I use Virtualbox to run Windows on my Mac laptop. (Virtualbox runs on Mac, Win, *ix)
After a recent laptop hardware failure I needed to run the VM on my desktop PC for a while, bought some extra RAM then realised that I was RAM-limited by the 32 bit OS on the desktop. So I installed Ubuntu 64 bit with Virtualbox in about half an hour. The Windows VM runs perfectly on there too.
What's not to love ? When everything you do is virtual, the base OS really ceases to matter.
That said, USB support is a bit primitive still in VirtualBox. Here's a post which may help.
February 23, 2012 at 5:54 am
I've used servers in virtual environments for a while now. Aside from some communication issues (which I hope were cleared up by subsequent versions of VMWare) and vendor requirements that preclude using a VM, my experience has been very good.
The only stumbling block I've run into is over-tasking the host. VMs provide economies of scale, but you have to perform a tightrope act between maximizing your VM investment and compromising the performance and/or stability of VMs on a host.
When I joined my current employer, they provided a VPN connection, but had some onerous requirements for the connecting PC (e.g. I refuse to install Norton). Solution: VMWare Server, running a bare-bones configuration. Fortunately we've moved on to a more accommodating VPN configuration, but the virtual machine was the answer at the time.
I personally miss VMWare LabManager, and hope we obtain a similar solution in the near future.
February 23, 2012 at 8:18 am
paul.knibbs (2/23/2012)
Of course, with your new setup, if you have a major physical drive failure you still need to reinstall whatever host OS you're using and put VirtualBox back on it... 🙂I've never been too convinced of the benefits of virtualisation for something as memory and disk intensive as SQL server, though. I suppose these days, with the actual databases often residing on SANs, that gets rid of the disk argument, but what about RAM?
True, but reinstalling a host is easy. Reinstalling WHS is a pain as it doesn't pick up the drives with the data, so they have to be copied off on another machine, added to WHS, copied back.
If you don't think virtualization works for SQL Server, you either have a) very busy SQL Servers, or b) you still think about slow virtual machines when we had 4GB limits on x86. Both the SQLServerCentral database servers (clustered) run in VMs, with 24GB allocated to each. The host machine has more RAM, and we rarely find performance issues or stresses from inside the VMs. I have dozens of friends, in real, live, large, corporate production environments running SQL Server in VMs.
February 23, 2012 at 8:36 am
It's probably nightmares engendered from the days when the company I worked for were trying to run a separate virtualised SQL server for every project...once you get 12 of the things on a machine with only 24Gb RAM, performance tends to suffer somewhat, especially when someone is trying to do a project build on a different virtual machine on the same server! 😉
February 23, 2012 at 8:52 am
From my experience with VM's, the upside is we can migrate VM's between physical servers very quickly and easily with very little downtime. This allows for better performance by making the most out of our available server resources. We can scale databases as we need to and perform our maintenance windows with hardly any inpact on our users. The downside is VM puts a greater strain on servers than just a single or multiple instance scenario, so assessing the impact on each virtual machine, and the resources it will need becomes a little more of a juggling act. But all in all, VMs are great, and the way things are going today, corporate side anyway. Also, the AMD-V and Intel VT Processors that are now out are actually designed with VM in mind. 😀
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
February 23, 2012 at 8:53 am
As the article alluded to, the trick to good worst-case performance with a virtual server is the same as the trick to good performance with a physical server: Share as little as possible.
Note that the average VM consultant often looks at the average case; this is identical to a pooled SAN consultant looking at the average case. This doesn't account for the best case... and, important to many but not all SQL Server installs, doesn't account for the worst case.
With VMs, SANs, NASs, and shared storage of all stripes, if you want to be able to quantify and control worst case performance, you need to control your spindles - dedicated spindles are a critical element in having predictable performance. If you share your spindles with another five apps (or VM's), and those five apps have a peak workload at the same time (perhaps during the end of year financial/auditing activity), your app is going to experience decreased performance in using those spindles.
The basic performance of the hardware doesn't change for VM's; heads can only move so fast, there's only so much bandwidth from spindle to controller, only so much from controller to storage network, only so much from, your latency is so high, etc. If you suddenly move from 88 dedicated, modern, 15k RPM spindles to 20 shared, modern, 15k RPM spindles, you're going to experience a reduction in peak performance. You're likely to experience a reduction in average performance (which may or may not matter to your app), and you'll likely experience a dramatic reduction in worst case performance (which more likely than not will matter to your app when it happens).
Beware "it's unlikely to happen" statements based on a normal distribution; end of the quarter/year reporting periods do not actually happen on an random independent trial basis from one app to the next.
With VM's, you not only have to control the spindles and other storage hierarchy, but also CPU, memory, memory ballooning, potential shared network ports, and so on. All VM's I'm aware of make controlling storage very easy. VMWare, at least, can set _minimums_ for CPU and RAM as well as shared amounts (and maximums, for that matter), so the VM administrators can prevent your SQL Server instance from being starved out by other apps.
In fact, you can achieve some cost and maintenance benefits of VMs and still give each SQL Server guest VM on a given host essentially dedicated CPU amounts, spindles, and RAM amounts; if the maximums for each add up to less than what the physical host actually has, there should be minimal contention (barring issues which what RAM belongs to what socket, which caches are shared with which cores, etc. etc.).
Essentially: Don't go from 50 cores, 300 spindles, and 512GB of RAM for 3 apps to 25 cores, 75 spindles, and 256GB of RAM for 8 apps and expect performance to remain identical all the time unless the peak workload before was less than the new environment's physical capabilities in the configuration it's in.
February 23, 2012 at 9:01 am
On a separate note, you can use vSwitches (virtual switches) or the equivalent to set up entirely independent networks of guest VM's which have no capability to interact with your physical network; this is extremely useful in testing.
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply