July 23, 2008 at 9:50 pm
Comments posted to this topic are about the item Virtual Conversions
July 24, 2008 at 12:47 am
Virtualisation is an interesting concept for DBA's indeed. We run our entire production server line in a virtualised ESX set-up in VMWare. We can dynamically upsize our production servers, or downsize them if needed, it's an easy process. We've done extensive testing before moving to a virtual environment and found no real differences in terms of performance or IO.
We've used this to our great advantage during our migration from NAV4 to 5: We shut down all non-essential virtual servers and upsized our production server to maximum values (16GB ram, multiple cores etc..etc..). Some scripts that ran for 8 hours on a typical system ran for only 2 hours on this upsized system. After the migration was done we downsized the production server again to reasonable specs, it's just a wonderful system to work with.
We do chose to make clean installations each time, we've migrated the old server to the new one but that was for a specific reason; we went from 32bit to 64bit. 😉
Do we run a large production environment? Not sure what you consider large, we have about 170+ concurrent users on a MS Dynamics NAV 5 environment, we do have thousands of tables. Everything is stable and reliable.
July 24, 2008 at 1:47 am
Er...yeah its interesting but HV requires X64 architechture.
Been playing with the whole VM thing at work and its probably gonna save us a bunch of cash and rack space in the data center.
I like the idea of backing up the VM and just transfering it to another physical machine running HV and its like up and running in the time it takes to transfer the file.
Makes disaster recovery a breeze. 🙂
Hiding under a desk from SSIS Implemenation Work :crazy:
July 24, 2008 at 4:30 am
This article pretty much mirrors what I've done before. We have requirements for lightly loaded SQL servers, so have used VMs to fill the need. We've used utilities before for creating VMs from physical servers as a means of moving old systems from obsolete hardware onto new kit whilst getting around compatibility problems. And we've used VMs as an adjunct to our DR processes.
All good stuff, and it's worked fine for us here.
Semper in excretia, suus solum profundum variat
July 24, 2008 at 5:48 am
I too have been involved with servers that we P2V'd (Physical to Virtual) them. The issue we would run into is the drivers from the physical machine are no longer supporting the same hardware. I would suggest it be best to start from a fresh virtual install if possible.
July 24, 2008 at 6:00 am
Cost of VM? On several engagements I've been on when the VM vendor states how much cash you'll save they don't mention anything about licensing costs. Or what about the costs associated with yet another server to manage?
And I'm curious about the folks who moved to the VM servers. Exactly how did you do your load testing?
Were there other VM's running on the same frame?
Did you use the load testing software that came from the VM vendor? (Really nobody would believe the vendor or the vendor's software would they?)
And while it's easy for you to move things around and stop and start the VM what real production benefit is that for the business user?
Just a couple of questions to find out if this is finally real or just a new flavor of kool-aid.
Bob
July 24, 2008 at 6:12 am
Bob Lee (7/24/2008)
Cost of VM? On several engagements I've been on when the VM vendor states how much cash you'll save they don't mention anything about licensing costs. Or what about the costs associated with yet another server to manage?And I'm curious about the folks who moved to the VM servers. Exactly how did you do your load testing?
Were there other VM's running on the same frame?
Did you use the load testing software that came from the VM vendor? (Really nobody would believe the vendor or the vendor's software would they?)
And while it's easy for you to move things around and stop and start the VM what real production benefit is that for the business user?
Just a couple of questions to find out if this is finally real or just a new flavor of kool-aid.
Bob
You ask some in depth questions about VM, I will give you some short answers due to time constraints.
We did extensive testing before deciding to switch to VM, we used several tools for this that monitor IO, memory, CPU etc..etc.. While there wasn't a real noticeable benefit speed wise, the biggest benefit here was the TCO: In situations where we need extra speed we can speed up our system 'within minutes', in case of server failure we can use snapshots and be up and running quickly and safely.
Our initial testing was done by simply comparing a running virtual server with a hardware server using several packages and many scripts and scenarios that we run into during production. We can monitor true hardware performance using the VMWare Infrastructure Client tools.
The bottom in our experience line is that the TCO is cheaper for VM.
Point to note in our case is that we are running on a dedicated VMWare Infrastructure server.
July 24, 2008 at 6:16 am
I am not convinced that virtual machines are the way to go for production environments. Yes, it saves costs in hardware, cooling systems, and power. But it places another layer of complexity in the system and provides another place to play the blame game and point fingers at when production systems fail.
I was part of a team that developed and supported a system that ran on several dedicated servers. Virtual machines were added to the mix to expand the system and distribute the workload. AHBL (All Hell Breaks Loose) happened after the VM systems were added. The systems running on the virtual machines crashed at least once a day, sometimes more than once a day! It turns out that the anti-virus running on each virtual machine was causing the production system to crash. Now, these systems were behind the firewall, not connected to the outside world, and had no access to email. The solution for system stability on the VM systems? The networking and infrastructure support group turned off the anti-virus.
July 24, 2008 at 6:23 am
If your installations are anything like the one's I've dealt with, the SQL Server is usually the -only- SQL Server, so not usually a good candidate for virtualization due to the high utilization and I/O requirements (sorry, .VHDs don't perform nearly as well as the straight physical disk/RAID). Although, I think keeping a Warm/Hot spare SQL Server instance (whether via replication/log shipping, or just restores from backups) would be an -excellent- use for a virtual server. Could you imagine the hero you'd be if your server failed and you switched over to the VM in a few minutes? (For those of us that aren't on expensive high-availability and clustered environments, that is.)
Today was the very first time I -watched- the podcast, versus just reading the blog. L-O-V-E-D the bloopers! Will probably always watch the podcasts now if you keep that up! 😉 (Mainly because it looks like exactly the type of thing I would do!)
July 24, 2008 at 6:33 am
We are having very good results with VMWare. So far, we have virtualized 91 servers onto 7 VMWare servers. We have more moves in the works. Obviously we are saving energy and space.
From a SQL Server standpoint, our most worked server is a SS2000 installation running 91 databases on two virtual servers configured as an active/passive cluster. Works great.
We are currently upgrading to SS2005. We did run into issues trying to run this on a virtual cluster. We believe it had to do with the 64 bit install. We have had no issues since backing away from the cluster installation. We have already migrated some of the aforementioned 91 databases over.
Looks like this also going to give us some interesting things we can do in the DR arena.
Mike
“I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant.”...Robert McCloskey
___________________________________________________________________
July 24, 2008 at 6:52 am
mbricker (7/24/2008)
quote]
Help me to understand what you gain from an active/passive cluster in a vm? Are both of them on the same frame? If so doesn't this eliminate the protection of the two most prevalent failure items? Power Supply and Network?
Or do you have two separate VM frames with one VM instance for each node of the cluster? If it's the way it sounds, it's not much of a protection plan. Good thing you're looking into the DR stuff though. 😉
July 24, 2008 at 7:17 am
I believe they are on two different frames. We have 4 VM servers in our corporate data center and another three 20 miles away at our manufacturing campus data center. As I understand it, our vm servers also are on some kind of failover scheme.
I do know that the clusters allow us to patch servers or install software without losing our DB services.
You are right to a point. When we could not get SS2005 to run in 64 bit mode on a virtual cluster, our server people suggested we install the 32 bit version. The other SQL server DBA and I decided we had more to gain from having the 64 bit performance so we reinstalled as a non-clustered VM server. Besides, some of the DR advantages (like VM snapshots) don't work with the clusters.
Mike
“I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant.”...Robert McCloskey
___________________________________________________________________
July 24, 2008 at 7:19 am
VMWare is great for non production DB servers - uat and test and the like, most of the installations I've seen for Production servers are just too busy to be virtualized.
Making a copy is a snap!
I think it's great for development and test DB boxes, and the abiltiy to take a snapshot and roll back to a point in time is great, just can't squeeze the performance out of them yet.
I've also used Microsoft's virtual server, which is also a great product as well, but in some cases a little klunkier, especially when converting a physical to virtual machine.
July 24, 2008 at 7:30 am
This is an interesting topic I can talk to from personal experience. I'll start by saying, make sure you do it right in the first place. If the underlying infrastructure is not sound, your virtualization project is guaranteed to fail. With that said...
My former employer decided to start virtualizing because we had too many "server based" applications that were not fully utilizing the hardware we had purchased. When we consolidated two data centers into one, we quickly realized that at least 60 of our servers were severely under utilized (10% or less processor and memory utilization). Every time a department decided they needed a new application, they purchased a new server, sometimes more than one if the application needed SQL Server.
We started looking into our options and the only one available at the time was ESX. We started a conversation with Dell, who set it all up for us and provided the necessary training to maintain it. Dell also worked with us on a DR plan that would allow us to further take advantage of the virtual environments.
In the end, we were able to get rid of more than 60 physical servers in favor of virtual servers. Not only did the projected long term cost for those applications drop, the electrical and cooling requirements dropped as well (the room went from 90 degrees F to 75 degrees F without making any changes to the cooling systems). Since all of those virtual machines are stored on a SAN which is replicated to a duplicate SAN at a backup site, they are now able to bring critical applications back on line from the backup site if it is determined the primary site will be down for more than four hours.
As far as SQL Servers are concerned, we did virtualize several of them where the application vendors were particularly difficult to work with on support. We decided in these cases, it would be best to have a "dedicated" SQL Server for those applications. Running in a virtual environment for those servers actually improved performance over having dedicated hardware (we had a quad core physical server that after virtualization, ran much faster and had less problems). Other single app servers were consolidated to a single workhorse which is now better utilized. As far as my applications were concerned, they required dedicated hardware since I was seeing far too much traffic for a virtual machine to handle.
Moving from the physical hardware to the VM was easy with an application provided specifically for ESX. Moving from a VM back to hardware would be possible but not easy. I had created a machine image for the phone system computers so I could easily image one when it needed it or just needed to be replaced. I did create the image in a VM using Virtual PC and it did ultimately work well. The only challenge was making sure the image contained all of the possible driver combinations for the different chipsets and hardware varieties I would encounter. Once the image was complete, I ran sysprep and created the image. I'm not sure if you could take a live VM and convert it to physical hardware once it is up and running. It would be interesting to see that done as well in case the VM is getting overwhelmed and needs to move.
July 24, 2008 at 7:34 am
Mark Gerschutz (7/24/2008)
I too have been involved with servers that we P2V'd (Physical to Virtual) them. The issue we would run into is the drivers from the physical machine are no longer supporting the same hardware. I would suggest it be best to start from a fresh virtual install if possible.
Drivers shouldn't be an issue since the P2V process installs its own drivers to make the machine work as a VM.
Viewing 15 posts - 1 through 15 (of 46 total)
You must be logged in to reply to this topic. Login to reply