Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12345»»»

Virtual Conversions Expand / Collapse
Author
Message
Posted Wednesday, July 23, 2008 9:50 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 5:53 PM
Points: 33,063, Visits: 15,179
Comments posted to this topic are about the item Virtual Conversions






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #539833
Posted Thursday, July 24, 2008 12:47 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, April 9, 2009 12:43 AM
Points: 3, Visits: 24
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.
Post #539889
Posted Thursday, July 24, 2008 1:47 AM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Thursday, October 4, 2012 9:20 AM
Points: 583, Visits: 1,060
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
Post #539918
Posted Thursday, July 24, 2008 4:30 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Monday, July 21, 2014 4:57 AM
Points: 1,049, Visits: 3,002
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, sumus solum profundum variat
Post #539978
Posted Thursday, July 24, 2008 5:48 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Friday, May 18, 2012 10:15 AM
Points: 52, Visits: 55
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.
Post #540022
Posted Thursday, July 24, 2008 6:00 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Thursday, May 24, 2012 2:06 PM
Points: 97, Visits: 356
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
Post #540033
Posted Thursday, July 24, 2008 6:12 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, April 9, 2009 12:43 AM
Points: 3, Visits: 24
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.
Post #540046
Posted Thursday, July 24, 2008 6:16 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Friday, July 11, 2014 7:13 AM
Points: 375, Visits: 596
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.
Post #540048
Posted Thursday, July 24, 2008 6:23 AM


Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Friday, July 26, 2013 12:47 PM
Points: 53, Visits: 125
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!)
Post #540052
Posted Thursday, July 24, 2008 6:33 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Wednesday, July 23, 2014 10:59 AM
Points: 2,568, Visits: 2,219
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

The more you know, the more you know you don't know.

_____________________________________________________________________________

A word to the wise ain't necessary, it's the stupid ones who need the advice ...Bill Cosby
Post #540058
« Prev Topic | Next Topic »

Add to briefcase 12345»»»

Permissions Expand / Collapse