SQL Server and virtualisation
-
It has been proposed, by our Techical people, that our SQL servers are replaced by a server using virtulisation ( one server split down as if it were many servers. The server names won't change)
Would SQL Server support this?
Madame Artois
-
SQL Server can be installed on a Virtual server, however resist throwing a fit if need be, unless they are talking about "big iron" for the server.
Virtualization effectively divides the server's resources by the number of virtual servers, less the base server. So if you are going from two 4 processor 8GB 300mbs 2 controller RAID 10 array dedicated servers to a 8 processor 16GB 300mbs 4 controller RAID 10 array virtual server with two SQL Server instances, you will still loose due to the loss of 1+GB of memory and drive contention for the "shared" array for the base server instance.
IMHO database engines do not fit well into the virtual model as they are way too memory and disk intensive for shared resources.
I am very sure that an argument can be made for SQL Server virtualization, but not by me.
Andy
-
We have used SQL Server on VMs in a non-production mode. We have also used SQL Server on VMs for disaster recovery testing. Speaking with a well-known company that does storage solution consulting, some organizations are using VMs to abstract the hardware since Microsoft hasn't ever actually gotten than HAL completely right. This allows them to bring SQL Servers up very, very quickly by restoring the VMs. Since it's a VM, no issue about dissimilar hardware. All the organization has to do is install VMware or Microsoft's product, create the VM, and restore the VM backup. If they've copied the VM intact, then they are restoring that instead. We chose this latter approach.
K. Brian Kelley
@kbriankelley -
"We have used SQL Server on VMs in a non-production mode. We have also used SQL Server on VMs for disaster recovery testing. "
When you wrote this, did you mean that you have not used virtual servers for live databases? We have some 35 plus databases in various live, test, and training environments ;some of which are web based applications. They can be accessed by 2000 plus staff though not all at the same time. In light of the comments by David I'm beginning to feel nervous.
Madame Artois
-
If by live you mean production, not really, but this isn't because of an inherent limitation in VM. For production SQL Servers we go with big iron (clustered) and therefore there's not a need to use VMs. We do use VMs in production for other systems, some of them critical to the business, just not SQL Servers.
You may want to do some looking on both the Microsoft and VMware sites as both have put out whitepapers recently on how best to virtualize the server environment. That may give you a better idea, based on your business and technical needs, of how feasible VMs are for your organization.
K. Brian Kelley
@kbriankelley -
Perhaps, someday VM will be a good fit for Production SQL Server - just not today. I stopped by a booth at TechEd to get a closer look at Virtual Server R2. It is getting better, but I wouldn't trust my valuable production data on it yet. If they want to save rack space, have them consider consolidation on a 64-bit platform. It can save lots of $$$ on Licensing costs.
Hope this helps!
Rick...
-
Keep in mind that saving rack space is only one reason to go VM. There are others:
- Hardware layer abstraction (can be key for DR plans)
- Maximize use of hardware (how many folks have servers running at 20-30% utilization because an app can't play nicely with others)
- Increase uptime (ESX w/ Vmotion is a good example)
I know there are some folks who are using VMware (ESX) for their SQL Servers in production, mostly because of the first advantage.
K. Brian Kelley
@kbriankelley
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply